Bug 326018

Description David Williams 2010-09-22 19:35:25 EDT

And it may already be standard enough ... but, since not documented, figured I'd open this request so the p2/releng teams would know its needed. 

And, I am talking about the jar comparator (org.eclipse.equinox.p2.repository.tools.jar.comparator) ... not sure if a universal standard can or should be achieved. 

But, here's the backgound, usecase, and assumptions so far. 

In WTP, I recently added the comparator to one of our mirror tasks. Very cool so far. But, the log routinely generates several hundred messages, most (or all) of which can be normally ignored (such as the comparator saying the about.mappings file has changed ... we can ignore that, since just differs by the date of the build). But having several hundred is too much "noise" so hard to see if something significant is in there. 

So, one approach, I wrote a little Java test (ran as a releng unit test) which parses the logs, and trims out messages that match certain patterns. For best handling, I wanted to treat messages associated with certain conditions as a unit, so the log cleaner could be smarter. 

As an example, we get some "failed" comparisons because the comparator can not read certain jars ... but it can not read them on purpose, they are part of some tests we run to make sure our code handles invalid jars. So, we want to ignore that invalid-jar message but only if it occurs in a known case ... if some new invalid jar were to show up, we would not want to ignore that. 

So what I've found, so far, is the comparator log starts with an identifying line, then a blank line, then the rest is sets of 3 or 4 lines, each set being for one difference found. Below is my interpretation of the message lines, and a couple of examples from our WTP comparator logs: 

! line 1      summary             type (canonical, archive, etc), bundle, and version info 
! line 2      comparison          exact repositories being compared
! line 3      reason              brief description of the differnce found (or errors or exceptions in processing)
! line 4      extraDetail         a bit more details about errors found (variable, only a few messages have 4 lines)

canonical: osgi.bundle,org.eclipse.wst.jsdt.web.core.source,1.0.400.v201007311522
Difference found for canonical: osgi.bundle,org.eclipse.wst.jsdt.web.core.source,1.0.400.v201007311522 between file:/shared/webtools/committers/wtp-R3.3.0-I/20100921193530/I-3.3.0-20100921193530/repository/ and file:/shared/webtools/projects/wtp-R3.3.0-I/workdir/I-3.3.0-20100922161612/buildrepository/wst-sdk
In about.mappings, the property "0" has different values: "<missing argument>" and "<missing argument>".


canonical: osgi.bundle,org.eclipse.wst.jsdt.core.tests.model,1.0.400.v201008090606
Difference found for canonical: osgi.bundle,org.eclipse.wst.jsdt.core.tests.model,1.0.400.v201008090606 between file:/shared/webtools/committers/wtp-R3.3.0-I/20100921193530/I-3.3.0-20100921193530/repository/ and file:/shared/webtools/projects/wtp-R3.3.0-I/workdir/I-3.3.0-20100922161612/buildrepository/wst.tests
IOException comparing /shared/webtools/tmp/sourceartifactworkspace_JavaSearch_corrupt_jar7525248058409888526.jar and /shared/webtools/tmp/sourceartifactworkspace_JavaSearch_corrupt_jar472031197553904842.jar
Error opening zip file /shared/webtools/tmp/sourceartifactworkspace_JavaSearch_corrupt_jar7525248058409888526.jar


So ... the point, after that long intro ... I'd like my unit test not to 'break' just because the log output format changes in the future. 

As long as it stays as it is with three or four lines per message, with those type of meanings similar to how I interpreted them above, and with a blank line between _sets_ of messages, then I my little unit test should be fine. 

Just wanted to open this enhancement request, so you'd know assumptions are being made about the log format ... and/or give advice if you'd recommend some other approach.