Community
Participate
Working Groups
This is the patch for the changes that I have made
The test build that Kim ran failed with the same exception than the last time (https://build.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-equinox-test/150/console) 100512/scripts/genericTargets.xml:107: Processing inclusion from feature master-ecf: Bundle org.eclipse.ecf_3.1.0.v20100528-1416 failed to resolve.: Missing required plug-in org.eclipse.equinox.common_[3.5.0,3.6.0). Missing required plug-in org.eclipse.equinox.registry_[3.4.0,3.5.0). Missing required plug-in org.eclipse.ecf.identity_[3.1.0,3.2.0). This error seems to be caused by the rewriting of the manifest that happens at build time where the ranges of the required bundles are being restricted.
What's happening here is so far a total mystery to me. I'm adding Markus Kuppe from ECF as he's been working with our builder and may have some answers.
Something must have changed with ECF's build process, as 3.1.0.v20100508-2345 does not have these version ranges. They are not in the manifest in CVS. PDE/Build does not modify manifests in this way.
Any progress?
(In reply to comment #4) > Any progress? I have not heard anything back from Markus K. He did the recent ECF builder changes that resulted in this (I'm currently not sure if it's change of Buckminster version or builder configuration or what). Unfortunately, it's evening now in Europe, so he's probably not responding until Sat am local time. I'll do everything I can to get it repaired asap and get some new version in for RC4...again as soon as I can.
With Buckminster 3.5 I was able to produced what I think to be a valid build [0]. At least the manifest does not define any version ranges anymore. Are there other plausibility/sanity checks I can do before you fire off a new platform build? Markus [0] https://build.ecf-project.org/hudson/job/I-HEAD-platform.feature/lastSuccessfulBuild/artifact/
Would it be desirable to fully automate the ECF contribution to detect such bugs as this one earlier in the game? E.g. the ECF build can generate a map file fragment automatically or p2 may consume the p2 repo directly. This would also free Scott from manually posting the map fragment.
FWIW bug #309141 and bug #309147 track the Buckminster enhancement that has caused this issue.
After a successful test build using the new jars from ECF, I have released these changes for RC4.
Out of interest, I ran the feature version range check tool again the latest ECF build (http://download.eclipse.org/rt/ecf/3.3/helios/site.p2/). It appears that the ECF "include" features still have 'non-strict' ranges. For example: <feature id="org.eclipse.ecf.server.generic.feature" label="ECF Generic Server" version="1.0.0.v20100601-1333" provider-name="%providerName"> <includes id="org.eclipse.ecf.remoteservice.feature" version="1.0.0.v20100601-1333"/> <plugin id="org.eclipse.ecf.server" download-size="0" install-size="0" version="2.0.0.v20100601-1332" unpack="false"/> <plugin id="org.eclipse.ecf.server.generic" download-size="0" install-size="0" version="3.0.0.v20100601-1332" unpack="false"/> </feature> (notice the includes) has the following requirements in the IU: [org.eclipse.ecf.server.generic [3.0.0,3.1.0), org.eclipse.ecf.server [2.0.0,2.1.0), org.eclipse.ecf.server.generic.feature.feature.jar [1.0.0.v20100601-1333], org.eclipse.ecf.remoteservice.feature.feature.group [1.0.0,1.1.0)] Notice the ranges.
Perhaps the Buckminster guys can help in getting the right build infrastructure/configuration setup. CCing Thomas
What version of Buckminster is being used? The one that's on our update sites now should not give this result.
(In reply to comment #11) > Perhaps the Buckminster guys can help in getting the right build > infrastructure/configuration setup. CCing Thomas No need to bother Thomas. Bug #309147 explains it just fine. :-) And a new build with strict/perfect version ranges (pde.feature.range.generation=perfect) is already in the making [0]. [0] https://build.ecf-project.org/hudson/job/R-HEAD-sdk.feature/56/
FWIW originally dealt with ECF's platform/p2 contribution (org.eclipse.ecf.platform.feature) but apparently has drifted off to our Helios contribution (org.eclipse.ecf.sdk.feature). I assume platform/p2 does not need a new build as it does not consume the feature.xml anyway?
(In reply to comment #14) > FWIW originally dealt with ECF's platform/p2 contribution > (org.eclipse.ecf.platform.feature) but apparently has drifted off to our Helios > contribution (org.eclipse.ecf.sdk.feature). I assume platform/p2 does not need > a new build as it does not consume the feature.xml anyway? Right. The p2/platform integration build does not need to be redone, but as a precautionary measure I would like to do a build of the platform feature (just for us/ECF) with the new build configuration...and I'll check the manifest.mf contents...so that if another platform build/contribution is needed, we can be assured that the problem represented by this bug won't recur at the last second.
Scott, just to be really clear, is there anything that you need p2 to do?
(In reply to comment #16) > Scott, just to be really clear, is there anything that you need p2 to do? No, not for the issue associated with this bug. We will produce another p2/filetransfer contribution *only* if a new/major bug is identified in filetransfer...and if this happens we now have the Bucky builder such that it will not re-introduce the issue experienced last week that originated this bug. If no new/major bugs are identified in filetransfer, then the RC4 contribution (comment 9) will be our last one for the platform. For the future (after Helios), it would be great if you would open a platform releng bug so that we/ECF could adopt a new releng process for contributing to the platform. Specifically, we would like to create a p2 repo, and have the platform build consume filetransfer from that repo, rather than what we've been doing...i.e. us creating a map file fragment specially for the platform (bug 219499). It would be much easier for our own releng if we could avoid this map file totally, and just generate a single p2 repo for the platform to consume the necessary filetransfer bundles. So, I'm resolving this bug.
