Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325037

Summary:	Slightly inconsistent results of repos versus zips
Product:	[WebTools] WTP Releng	Reporter:	David Williams <david_williams>
Component:	releng	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:	David Williams <david_williams>
Severity:	normal
Priority:	P3
Version:	3.10
Target Milestone:	3.10.0
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description David Williams

2010-09-11 17:54:42 EDT

While testing/investigating another issue (bug 323245) I found that the results of installing via zip files, and installing via p2 repository were slightly different. All the feature and plugins and versions "matched", but when doing a 'diff', some plugins (from Orbit) we flagged as different (even though they had exactly same name. Upon investigation, these differed by the date they were signed on (which made the signature files/hashes slightly different). One was signed on 9/2/10 10:23 PM the other signed on 9/10/10 4:59 AM.

So, for one, this is an indication that we (WTP, or someone) are probably re-signing those jars unnecessarily because we _should_ be pulling from the Orbit repo of R20100519200754 so any signatures should be on or before that date.

For two, we may not be getting those jars from the "right" repo. We sort of leave it up to PDE's use of p2, and as far as I know, it allows p2 to use mirrors. See bug 324983 for some other indication that builds are doing that.

Hence, once action, for this bug, is to make sure we always use
-Declipse.p2.mirrors=false
for any time p2 might be used to do some "pull" or "mirror" operation.

Probably easiest way is to to specify
export IBM_JAVA_OPTIONS=-Declipse.p2.mirrors=false
as an environment variable, since we know, for our official builds on build.eclipse.org, it is always an IBM VM that's used.

Should also do that too, when "testing repos" ... to make sure getting what we actually put on eclipse.org ... if mirrors are different, that would either be a matter of timing, or another bug that should be investigated separately.

Second action is to look closer at our logic to prevent re-signing Orbit jars, and make sure that's working.

Comment 1 David Williams

2010-09-11 17:59:35 EDT

Note that is was the runtime-only zip file that had the earlier signed jars. 
The SDK runtime had the same, later signed, jars as the repo install. 

For the record, the following is the list of "Orbit jars" that had different date signatures in the runtime-only zip vs. repo: 

javax.wsdl_1.5.1.v201005080630.jar 
javax.xml_1.3.4.v201005080400.jar
org.apache.commons.codec_1.3.0.v20100518-1140.jar
org.apache.commons.logging_1.0.4.v201005080501.jar
org.apache.xerces_2.9.0.v201005080400.jar
org.apache.xml.resolver_1.2.0.v201005080400.jar
org.apache.xml.serializer_2.7.1.v201005080400.jar

Comment 2 David Williams

2010-09-14 02:49:21 EDT

There were two problems. We were resigning the orbit zips. Doesn't really harm anything, except to "make the different". This was due to a bug in our WTP ant task to "update pack properties" file. When originally written, I wrote it assuming the file lay out was like a traditional zip file (eclipse/plugins, eclipse/features). but now that we use repos, the plugins and features are at the top during this time, so we were simply not finding any, much less any that were already signed. Do, I fixed that ant task to work with either structure,

Even after fixing that, I did get some variability, I think, on some builds but after specifying p2.mirrors=false, they were all consistent, with expected date.