Community
Participate
Working Groups
When trying to load EMF onto Eclipse 4.0 some of the plugin won't load, like org.eclipse.emf.edit.ui_2.6.0.v20100427-1455 This seems to be because while the MANIFEST in CVS is fine, the build inserts restrictive ranges: i.e. it took org.eclipse.ui.workbench;visibility:=reexport, from the MANIFEST and turned it into org.eclipse.ui.workbench;visibility:="reexport";bundle-version="[3.6.0,3.7.0)" The 4.0 workbench is version 3.100.0 and so we can't load emf that works with the e4 visual editor. 3.100.0 is API compatible with 3.6.0. Is this something that's easy to simply turn off? Or only generate lower bounds? PW
This has always been the case with EMF (i.e., that version ranges aren't explicitly managed, but rather generated/inserted by the build), with the exception of M6, which was built with Athena. With M7 we have restored the dependency version ranges (using Buckminster).
(In reply to comment #1) > This has always been the case with EMF (i.e., that version ranges aren't > explicitly managed, but rather generated/inserted by the build), with the > exception of M6, which was built with Athena. With M7 we have restored the > dependency version ranges (using Buckminster). How does the build determine what the upper bound should be? We have org.eclipse.ui.workbench version 3.100.0, which we believe will work fine with EMF edit. In fact if it is not compatible we will consider this our bug and we will fix it on our side. Your ranges seems to unnecessarily prevent an older version of EMF from running on a newer version of the platform.
*** Bug 312046 has been marked as a duplicate of this bug. ***
Details of how the range is computed can be found in bug 309141. Note that this is the same algorithm we have been using for the last few years now. The reason for the "strict" upper bound is that, based on what a minor version number increment means, we cannot guarantee compatibility based on the numbers alone. We cannot afford to blindly claim to support a higher version without more than a belief that it will work fine. If we relax this constraint to include 3.100.0, what's to guarantee that this version of EMF will be compatible with versions 3.7.x through 3.99.x without knowing a priori what's changed in those releases?
(In reply to comment #4) > Details of how the range is computed can be found in bug 309141. Note that this > is the same algorithm we have been using for the last few years now. > > The reason for the "strict" upper bound is that, based on what a minor version > number increment means, we cannot guarantee compatibility based on the numbers > alone. We cannot afford to blindly claim to support a higher version without > more than a belief that it will work fine. If we relax this constraint to > include 3.100.0, what's to guarantee that this version of EMF will be > compatible with versions 3.7.x through 3.99.x without knowing a priori what's > changed in those releases? In general, you can only believe the contract [1]. 3.6.x is API compatible with 3.100.x because of that. Assuming the platform honours [1] then (barring the bugs that creep up from time to time) EMF would continue to work. However in this specific case, we know that EMF edit support won't work on Eclipse 4.0 because of auto-generated version ranges ATM. If it wasn't there then testing and use by (amongst other things) the e4 visual designer would confirm if it worked or point out potential problems (in the compatibility layer or EMF itself). [1] http://wiki.eclipse.org/Version_Numbering
Apologies, I see now that the algorithm as implemented in the current build is actually more restrictive than it used to be. The intent was to exclude the next major version, as per the contract you've referenced. I'll work with the team to get this addressed ASAP.
OK, I've been able to produce more tolerant version ranges by changing the build rule from 'equivalent' (the default) to 'compatible'. We'll post an integration build with the changes on Monday.
(In reply to comment #7) > OK, I've been able to produce more tolerant version ranges by changing the Excellent. Thank you, PW
An integration build (I201005101618) with the fix is now posted (see http://www.eclipse.org/modeling/emf/downloads/?showAll=1&hlbuild=I201005101618&project=emf#I201005101618) and is also available via the integration build site (http://download.eclipse.org/modeling/emf/emf/updates/2.6.0-I-builds).
Closing all fixed releng bugs.
