Community
Participate
Working Groups
As everyone will recall, "at the last minute", we turned "off" the baseline-replace functionality for our build, due to bug 406465. This bug of "slight different" was caused because, I forgot, we also have a "post-build" mirror/comparator task as we create our final p2 repository. So, at that point, if a "matching" jar is found in reference repo, it will be used, instead of the one from the current build. This was done this way as a sanity check on the new Tycho/Maven comparator/replace function ... and indeed, when "ok", there are no "differences" found and no substitutions done (since, it would have already happened, when baseline-replace function is turned on). So, as a result, during the final "post-build" mirror/comparator task, when we create our M7 repo, there were some cases of "old bundles" being substituted, instead of the ones that were just built (and distributed in zips, etc.). Luckily, it appears, the only differences found were found for some old bundles that have different "Eclipse-SourceReferences" values. See http://download.eclipse.org/eclipse/downloads/drops4/I20130502-0800/buildlogs/comparatorlogs/postbuild-comparatorlog.txt Besides the Eclipse-SourceReferences difference, there was a doc bundle, different between distribution and our M7 repo Difference found for packed: osgi.bundle,org.eclipse.platform.doc.isv,4.3.0.v20130426-2121 between http://download.eclipse.org/eclipse/updates/4.3-I-builds/I20130428-2000 and file:/shared/eclipse/builds/4I/siteDir/eclipse/downloads/drops4/I20130502-0800/repository/ Binary file "reference/api/deprecated-list.html" is different. To illustrate the Eclipse-Source reference issue, I looked at one bundle in detail. org.eclipse.equinox.p2.repository.tools_2.1.0.v20130327-2119.jar In distribution, it is: Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/equino x/rt.equinox.p2.git;path="bundles/org.eclipse.equinox.p2.repository.t ools";tag="I20130502-0800";commitId=72d4d8ad4ca3e370a4fc2812612b67c13 ce9919f In Repo, it is: Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/equino x/rt.equinox.p2.git;path="bundles/org.eclipse.equinox.p2.repository.t ools";tag="I20130402-0800";commitId=7184672bf7e9aed74dc896deea71041b5 70ffb9c There are, likely, so many of these differences (that make no difference in the code) due to the way we've changed the rules on POM changes effecting versioning etc. That's all I could think of.
Created attachment 230439 [details] differences in versions/qualifier between final candidate and last comparator "on" build As sort of a sanity check on our final build -- to make sure the build-time comparator change didn't make some odd difference -- I took one distribution (linux, SDK) and compared the list of plugins in the final M7 candidate, and the "last good build" that had the build-time comparator turned 'on'. I20130502-0800 vs. I20130430-2000 As the attached list shows ... nothing too odd. I can explain nearly all of them ... such as the branding bundles changed, as they always do ... some p2 changes as would be expected due to their rebuild request ... the last minute version change in e4.ui.di ... The only change I was not expecting was in SWT: < org.eclipse.swt_3.102.0.v20130430-2123.jar < org.eclipse.swt.gtk.linux.x86_64_3.102.0.v20130430-2128.jar < org.eclipse.swt.gtk.linux.x86_64.source_3.102.0.v20130430-2128.jar --- > org.eclipse.swt_3.102.0.v20130501-2135.jar > org.eclipse.swt.gtk.linux.x86_64_3.102.0.v20130501-2152.jar > org.eclipse.swt.gtk.linux.x86_64.source_3.102.0.v20130501-2152.jar But ... nothing I'm concerned about.
So, normally a difference in distributed zip jars, and repo site jars would be a reason for rebuild ... but ... since appears to only effect Eclipse-Source References, and presumably then the difference between one commit and another would be POM changes ... I won't be asking for a respin ... though, others may if you feel this is bad enough. [Note: in theory, I could just re-generate the final repo from the one still on the build machine after tweaking some scripts ... but ... to "tweak" a milestone doesn't seem to be a great way to deliver the final version either.].
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
