4

Eclipse Neon (4.6) release removed org.eclipse.core.runtime.compatibility, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=476405 where this was mentioned.

Several of our plugins depend on this, and now will not install into this version of Eclipse.

Is there an easy workaround for this, short of reworking these plugins to remove this dependency, which may be a large task?

Marshall Schor
  • 53
  • 1
  • 5

2 Answers2

2

org.eclipse.core.runtime.compatibility is the compatibility layer for Eclipse 2.x (before OSGi: no META-INF/MANIFEST.MF, only plugin.xml, etc.). Eclipse 3.0 was released with this compatibility layer 2004.

Just remove this dependency and look for compile errors. Probably, there will be none and you are done.

howlger
  • 31,050
  • 11
  • 59
  • 99
  • I removed the dependency, and it compiled without error, and installed, but didn't intialize properly. I guess I have to go thru and update that part. – Marshall Schor Jun 30 '16 at 14:59
  • Maybe _org.eclipse.core.runtime.compatibility_ is referenced also in _features.xml_ files and in the _config.ini_ file. Or the initialize issue is not releated to this. – howlger Jun 30 '16 at 15:07
1

To migrate our plugins, I did the following:

1) remove the dependencies on org.eclipse.core.runtime.compatibility, org.eclipse.core.runtime.compatibility.auth

2) In the instructions to the maven bundle plugin, changed the Bundle-Activator value from org.eclipse.core.internal.compatibility.PluginActivator to the plugin class itself, which now can have start / stop methods, in place of older startup and shutdown methods.

3) Changed the plugin's 1-argument constructor (which depended on the no-longer-available compatibility classes) to a 0-argument constructor.

4) found various alternatives for old version 2 ways of doing things, like getting the plugin's unique identifier (e.g. replace descriptor.getUniqueIdentifier() with getBundle().getSymbolicName())

Marshall Schor
  • 53
  • 1
  • 5