Community
Participate
Working Groups
The feature org.eclipse.equinox.executable had version: 3.3.200.v20090521-1800-7M-Fm-FI3UouOe61h3BYGC in the 3.5 GA release. In 3.5.1, the version is changed to 3.3.200.R35x_v20090724-7M-FneFF9aMTyz0pw04ONXn. This is very problematic since the new version is lower then the old one. The major, minor, and micro numbers are unchanged and the new qualifier is less ('R' < 'v'), Any query for the latest version of this feature will return the 3.5 GA release, not the 3.5.1 release. This effectively breaks our builds since we then run into conflict with the org.eclipse.rcp feature on what launcher bundles to use. Not sure if this feature is the only one affected by the new qualifier. I see them in a lot of places.
This is very easy to reproduce b.t.w. Just enter the "Install new software" wizard, select "all available sites" (this gives you both the Platform 3.5 and the Galileo site), check "Show only the latest version of available software" and look at the "Platform Launchers" feature. The one prefixed with R35x is nowhere to be found. Now uncheck "Show only the latest version of available sofware" and look again. The R32x feature shows up.
Moving to equinox since they own this feature.
Kim, is there a reason this was not caught by the version compare tool during the build?
The version compare tool only runs against the SDK. See bug 268851
(In reply to comment #0) > Any query for the latest version of this feature will return the 3.5 GA > release, not the 3.5.1 release. This effectively breaks our builds since we > then run into conflict with the org.eclipse.rcp feature on what launcher > bundles to use. How are you installing the executable feature? Did you use the delta-pack or install it into a target from the galileo repository? If you use a delta-pack is the work around to delete the old delta-pack from disk and download the new delta-pack for your target?
(In reply to comment #5) > How are you installing the executable feature? Did you use the delta-pack or > install it into a target from the galileo repository? If you use a delta-pack > is the work around to delete the old delta-pack from disk and download the new > delta-pack for your target? We're not installing it per se, we use the P2 repository to populate a target platform. We have a workaround for this now. We address the 3.5.1 repository directly instead of the parent composite. Apart from that, I think this issue needs to be resolved fairly quickly. In many cases, the target platform is not verified the same way that we do (with Buckminster) which instead will lead to successful builds that contain the wrong set of bundles. The real problem is then not discovered until conflicts occur when installing the final product.
In general, product builds against a target containing multiple versions of the delta pack will not succeed with this. I have upversioned the feature in CVS and tagged it. The question is what to do next?
Trying to determine the impact of this bug, I see the following: 1) The only platforms containing launcher fixes in 3.5.1 are cocoa.macosx and gtk.solaris. Other that these fragments, the 3.5.0 and 3.5.1 executable features refer to the same launchers. 2) Repo validation tools against the existing repositories are not expected to fail. If a new repository were created containing only the highest versioned launcher pieces, then that repository would fail validation. (I expect this is what happens with buckminster). 3) Building against targets containing both 3.5 and 3.5.1 is expected to fail at script generation time when building for one of the platforms in (1). (Other platforms are expected to succeed with the expected contents). The failure would be caused by the 3.5.1 launcher fragments resolving (they are singletons) and the higher 3.5.0 feature asking for the lower fragments. So, as far as I see, this is a problem when building cocoa or gtk.solaris and a) The target was manually created containing both 3.5 and 3.5.1. Workaround is to only include the 3.5.1 pieces. (Note that the advice given in 3.5.0 for creating targets with the deltapack for export was to put the delta pack in its own directory.) b) The target was automatically created by tools taking the highest versions out of the 3.5 update repo. Workaround is to consider only the 3.5.1 sub-repo on its own.
(In reply to comment #8) > 2) Repo validation tools against the existing repositories are not expected to > fail. If a new repository were created containing only the highest versioned > launcher pieces, then that repository would fail validation. (I expect this is > what happens with buckminster). > Our problem stem from the fact that our resolver discovered conflicting dependencies on the cocoa.macosx and gtk.solaris bundles. The features from which these dependencies originate are org.eclipse.rcp and org.eclipse.equinox.executable.
version was fixed
*** Bug 293892 has been marked as a duplicate of this bug. ***
