Comment 1 Esteban DUGUEPEROUX 2013-02-18 09:28:08 EST

Does this evolution breaks the backward compatibility with EMF release older than 2.9? Because we want to use CDO 4.2 with Eclipse 3.6 (using EMF 2.6).

Comment 2 Ed Merks 2013-02-18 12:39:42 EST

No, Eike is providing a fragment that will allow this new stuff to work with older releases of EMF.

Comment 3 Lothar Werzinger 2013-02-19 14:50:58 EST

I am experimenting with the CDO I-Builds and I get these build errors in my model plugins in the IDE:

The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.emf.ecore.impl.MinimalEStoreEObjectImpl. Fix the build path then try building this project	biz.tradescape.mmt.model.website		Unknown	Java Problem

The type org.eclipse.emf.ecore.impl.MinimalEStoreEObjectImpl cannot be resolved. It is indirectly referenced from required .class files	NavigationNodeImpl.java	/biz.tradescape.mmt.model.website/src/biz/tradescape/mmt/model/website/impl	line 33	Java Problem


Searching for MinimalEStoreEObjectImpl on the web lead me to this bugzilla entry.
What do I need to do to fix these build errors with the latest CDO I-Build?

Thanks in advance!

Comment 4 Eike Stepper 2013-02-20 01:46:13 EST

MinimalEStoreEObjectImpl has been added to EMF just the other week. We're aware that this is a problem for those that use newest CDO with older EMF. So we've added  the fragment org.eclipse.emf.cdo.ecore.retrofit to CDO, which adds the missing class to older EMF versions at install time. Are you sure that you've installed this new fragment?

Comment 5 Lothar Werzinger 2013-02-20 01:53:41 EST

After finding this bugzilla entry I was looking for the mentioned fragment and found org.eclipse.emf.cdo.ecore.retrofit

I added it to the target platform and it shows up in the "Plug-ins" view of Eclipse, but it did not make the build problems from comment 3 go away (I did a full clean and rebuild to be sure).

That's why I decided to post to this bugzilla entry.

Do I need to do anything else besides having the fragment in the TP?

Comment 6 Eike Stepper 2013-02-20 13:17:26 EST

Esteban, is it possible that you test our new CDO version with an older EMF version AND our retrofit fragment?

Comment 7 Eike Stepper 2013-03-13 03:06:42 EDT

I've now increased all lower bounds of dependency version ranges for Platform and EMF:

	Platform: 3.4.0 --> 3.5.0
	EMF: 2.4.0 --> 2.5.0
	
Commits:
cf49b7c79567c2428ecfca6d42867eda592cefca
1e999f4825d41c2a3b43fb6291fb6416410376ad
c57bf7e84145be55a5e4c54ed06c93203d5bf22a
227bea0427d3b593d397ad0b35422d7dbf051d42
ae4976ae6e18c5871d1838b927d95d905da84296
ef70e75984ccdd2c0eb2cec0da13ac7e1319d4ea
da7d59cf71edbd4b7333b38542072ed7c587224d
1de2ed6f432205d8b65580eb54594f34b433b6a3
554a4a177bd6a182a8fd8081969f9d3426732b6f
fff5e2745f2022717e44da61ac32d5123b82f3c2

Comment 8 Gregoire Dupe 2013-03-14 04:56:42 EDT

Hello,

I may misunderstood something but it may be something wrong with the fragment 'org.eclipse.emf.cdo.ecore.retrofit' :

I build MoDisco.using the CDO version contained in http://download.eclipse.org/modeling/emf/cdo/drops/I20130312-0633 with the M5 version of EMF. 

I get some compilation errors. It looks like that the class 'EStoreMinimalEObjectImpl' was missing whereas the fragment 'org.eclipse.emf.cdo.ecore.retrofit' was installed in the target platform.

Usually, we see the fragement in the "Plug-in dependency" section of a plug-in project, but I don’t see 'org.eclipse.emf.cdo.ecore.retrofit'.

I had a look to the fragment 'org.eclipse.emf.cdo.ecore.retrofit' : it looks all right.

Don't care about the MoDisco build: I assume it will build on Monday after the delivery of the M6 version of EMF.

Hoping this will help.
Regards,
Grégoire

Comment 9 Eike Stepper 2013-03-14 06:56:19 EDT

I'll experiment with different EMF versions and our retrofit fragment, again. Stay tuned...

Comment 10 Eike Stepper 2013-04-30 03:50:51 EDT

Ed and I debugged PDE to see why CDO's retrofit fragment is not picked up to augment the development classpath of org.eclipse.emf.ecore and the result is frustrating but clear:

1. At development time PDE requires the host plugin (emf.ecore) to declare the MANIFEST.MF header "Eclipse-ExtensibleAPI: true".

2. The org.eclipse.emf.ecore plugin didn't/doesn't do that and old EMF versions can't be changed accordingly.

3. At runtime OSGi will pick up the fragment and all is good.


So the problem is a pure development time problem, yet a very annoying one. One that's caused exclusively by PDE's strange attitude to (consciously) construct a different classpath at development time than OSGi would construct at runtime. We only see two ways to deal with the problem and this is only needed for developers who use CDO >= 4.2 and EMF < 2.9:

1. Use EMF >= 2.9. This is your best option! EMF 2.9 has many enhancements, such as drastically reduced footprint. And it's the first version of EMF that does not declare a restrictive limit on the Eclipse platform anymore. That means you can use EMF 2.9 with almost any (old) Eclipse.

2. Those who really don't want to use EMF >= 2.9 can:

2.1. import the org.eclipse.emf.ecore plugin from their target platform,

2.2. add the MANIFEST.MF header "Eclipse-ExtensibleAPI: true" and

2.3. export the plugin back to the target platform (increase the version qualifier in both the manifest and the jar name).

Comment 11 Eike Stepper 2013-04-30 03:58:56 EDT

For those being interested in the offending PDE code, it's in org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(BundleDescription, HashSet, Map, ArrayList, boolean):

  BundleDescription[] fragments = hasExtensibleAPI(desc) ? desc.getFragments() : new BundleDescription[0];

Very odd ;-(

Comment 12 Esteban DUGUEPEROUX 2013-05-03 02:59:33 EDT

Is there a bugzilla entry to track this PDE issue?

Comment 13 Eike Stepper 2013-05-03 03:10:49 EDT

I think that would be bug 340546. I just voted for it...

Comment 14 Eike Stepper 2013-06-27 03:29:58 EDT

Available in R20130613-1157 (4.2)