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
