Community
Participate
Working Groups
Follow-up to bug 469765. I20150707-0800 looks good, but when I compare M20150708-1000 to I20150603-2000 (Mars release), a few plugin JARs that should not have been touched are actually different in the maintenance build. I inspected the two org.eclipse.ant.core_3.4.0.v20150428-1928.jar and found that only the JAR archives are different, but their content is actually the same (same files, same bits). The one from M20150708-1000 is 180 bytes smaller. http://download.eclipse.org/eclipse/downloads/drops4/M20150708-1000/buildlogs/comparatorlogs/buildtimeComparatorSignatureOnly.log.txt says: ---- 61. eclipse.platform/ant/org.eclipse.ant.core no-classifier: different META-INF/ECLIPSE_.RSA: different META-INF/ECLIPSE_.SF: different classifier-sources: different META-INF/ECLIPSE_.RSA: different META-INF/ECLIPSE_.SF: different The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [pack200, sources] ---- => It looks like the JAR has been modified after having been replaced with the baseline version. That's shouldn't happen, but I can't explain why it did.
This is interesting!? Both comparator repositories were "primed" with I20150603-2000. I assumed you looked in an "installation"? I've looked at repositories on 'downloads' and there they are same size, no differences ... so perhaps (somehow) related to the unpack200 process? $ diff 4.6-I-builds/I20150707-0800/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar 4.5-M-builds/M20150708-1000/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar $ ls -l 4.6-I-builds/I20150707-0800/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar 4.5-M-builds/M20150708-1000/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar -rw-rw-r--+ 1 david_williams eclipse.platform.releng 107420 Jul 8 12:07 4.5-M-builds/M20150708-1000/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar -rw-rw-r--+ 1 david_williams eclipse.platform.releng 107420 Jul 7 09:58 4.6-I-builds/I20150707-0800/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar $ ls -l 4.6-I-builds/I20150707-0800/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar.pack.gz 4.5-M-builds/M20150708-1000/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar.pack.gz -rw-rw-r--+ 1 david_williams eclipse.platform.releng 72410 Jul 8 12:06 4.5-M-builds/M20150708-1000/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar.pack.gz -rw-rw-r--+ 1 david_williams eclipse.platform.releng 72410 Jul 7 09:58 4.6-I-builds/I20150707-0800/plugins/org.eclipse.ant.core_3.4.0.v20150428-1928.jar.pack.gz
I don't think pack200 was involved in my installs. I didn't use any update site. I downloaded complete Eclipse SDK builds like this and extracted them via "jar xvf <path-to-zip-file>": http://download.eclipse.org/eclipse/downloads/drops4/I20150707-0800/download.php?dropFile=eclipse-SDK-I20150707-0800-win32-x86_64.zip I verified that 7-Zip and the Windows Explorer also produce an org.eclipse.ant.core_3.4.0.v20150428-1928.jar of size 107600 for eclipse-SDK-I20150707-0800-win32-x86_64.zip, eclipse-SDK-I20150707-0800-linux-gtk.tar.gz, and eclipse-SDK-4.5-win32-x86_64.zip => Looks like the 180 bytes are added before the I-builds are packaged.
My guess is all those that are "identical, but different" have nested jars in them. Markus, can you check your installs? I only ask since you presumably have a setup already for easy checking? And, if that is the case, can you check if the differences are due (entirely) to the nested jar? Not sure why that would be, since we are using identical versions of Tycho and CBI (tools) and input. So ... either, the "packaging" phase picks up the wrong (but identical contents) version of the jar some how, or ... There is something that unzips and rezips the jar files during packaging? Though, not sure why even that would produce different results? One way or the other, seems like something indeterminate about our builds, and everyone knows how much I hate that! Mikael, any ideas ... I'm wondering if related to the "signing the executable". When the CBI-executable-signer is looking for something to sign, does it unzip jar files to do so ... or ... perhaps is has too! If so, do you have any ideas on what might be causing this difference? Seems if nothing else, we should make sure it does not "re-zip" jar files in which it find nothing to sign, but instead, just use the original. Pretty sure by the packaging/arching point, we are well past anything to do with "signed jars" and similar things that have to be done before the comparator runs. If nothing else, this may be important to make sure checksums all make sense, though, as far as I know, checksums are not literally used in current "packaged" contents. (And, again, this does not seem to be an issues in the repository versions ... just the packaged versions.
(In reply to Markus Keller from comment #2) > I don't think pack200 was involved in my installs. .... > > => Looks like the 180 bytes are added before the I-builds are packaged. One theory I had was that the "package/archive" function (still) does use pack.gz files, since (I am pretty sure) it uses something similar to p2.director to create the installs, AND, while normally p2 director would use jar files directly from a "local repo", I doubt that Tycho knows at that point that the repo is local, so might use the pack.gz file. I tested this theory by using (java 8) unpack200 to create a "new" jar file, and it was 7 bytes different in size, than the jar in the repository. So ... not 180 .. you observed, but ... sort of sounds like a possibility. I also tried Java 7, and it was 707 bytes smaller. I should note, java 7 unpack200 and java 8 unpack200 report the same version: $ /shared/common/jdk1.8.0_x64-latest/bin/unpack200 -V unpack200 version 1.30, 07/05/05 But, guess it depends on available library? Not to mention, what it was conditioned and pack200ed with in the first place (which is supposed to be Java 8). End the end, I'm not sure we can place much significance on "jar diffs" ... the only thing that matters is unzipped file differences ... which, as I understand it, there are none, in this case. See also the old bug 410948. All of these discrepancies makes me wonder if the md5 checksums in p2 repositories can possibly be accurate or consistent (especially "in composites").
Just realized the "7 byte" difference I reported was all within the I-build. If I do the same thing with the M-build (using repository files) then the M-build is also 7 bytes larger when using unpack200 ... in other words, would still be equal to I build size ... so ... maybe isn't that relevant to this bug, after all?
Just ran across this old bug. I am assuming there is no more work for us to do here after a quick skim read. I think "compression" (the jar files) are variable depending on the version of Tycho used as well as the "libraries" installed on OS. As long as "contents" are the same, all is good. Please re-open if there is more to do.
