Great work! I would probably have named the first one "src:eclipse-equinox-bundles", unless there is a good reason not to do that. Same for "libequinox": why not libeclipse-equinox? It's more verbose, but I don't know if equinox is known outside of Eclipse? Cheers, Vincent
2018-07-05 23:46 GMT+02:00 Emmanuel Bourg <ebo...@apache.org>: > 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 > >
