Hi all,
Among the issues we have to handle for the transition to Java 11 there
is a difficult one with aspectj and eclipse. aspectj fails to build with
Java 9+ (#873213) and needs an upgrade. Unfortunately this also implies
an update of eclipse (aspect/1.8.9 is the last version compiling with
eclipse/3.8.1) and this is unlikely to happen in the near future. The
dependency of aspectj on eclipse is also blocking the removal of eclipse
(we can't do without aspectj, it's required by libspring-java).
So following Markus idea of extracting libequinox-osgi-java from eclipse
I investigated if it would be possible to do the same with the parts of
eclipse used by aspectj. I started with the org.eclipse.equinox.common
bundle. I tried building with tycho but I stumbled on several issues
(#902982 to begin with). So I resorted to building with a naive Ant
script and it worked. I pushed the experiment to the other bundles used
by aspectj and I now have the following new packages (and associated
OSGi bundles):
src:equinox-bundles
(https://github.com/eclipse/rt.equinox.bundles )
libequinox-app-java (org.eclipse.equinox.app)
libequinox-common-java (org.eclipse.equinox.common)
libequinox-preferences-java (org.eclipse.equinox.preferences)
libequinox-registry-java (org.eclipse.equinox.registry)
src:eclipse-platform-runtime
(https://github.com/eclipse/eclipse.platform.runtime )
libeclipse-core-contenttype-java (org.eclipse.core.contenttype)
libeclipse-core-expressions-java (org.eclipse.core.expressions)
libeclipse-core-jobs-java (org.eclipse.core.jobs)
libeclipse-core-runtime-java (org.eclipse.core.runtime)
src:eclipse-platform-resources
(https://github.com/eclipse/eclipse.platform.resources )
libeclipse-core-filesystem-java (org.eclipse.core.filesystem)
libeclipse-core-resources-java (org.eclipse.core.resources)
src:eclipse-platform-text
(https://github.com/eclipse/eclipse.platform.text )
libeclipse-text-java (org.eclipse.text)
src:eclipse-platform-ui
(https://github.com/eclipse/eclipse.platform.ui )
libeclipse-core-commands-java (org.eclipse.core.commands)
I've opted for one binary package per bundle to keep things granular
unlike the current eclipse package. The upstream repositories have many
more bundles, I built only those required by aspectj.
Also, there is a mismatch between the version of the bundles and the
version of the Eclipse IDE which is used to tag the Git repositories.
For example in Eclipse 4.7.3 the org.eclipse.text bundle has the version
3.6.100. I've overridden dh_gencontrol in debian/rules to set the
version of the binary packages to the version of the corresponding
bundle. The Eclipse version is appended to the bundle version to avoid
reusing the same package version if the version of a bundle isn't
updated in a new release of Eclipse. So for the libeclipse-text-java
package the actual version is 3.6.100+eclipse4.7.3-1. The bundle version
is also used by the Maven artifacts installed in /usr/share/maven-repo.
With all this I'm now able to build aspectj/1.8.10 without depending on
the eclipse-platform package. I don't intend to push beyond the
immediate needs of aspectj (and maybe lombok). Anyone is free to pick
the ball from here and try to package the full Eclipse IDE.
How do you feel about the proposed naming and package organization?
Emmanuel Bourg