Build Multi-Release Jar #345
Conversation
* Uses separate runs of the maven-compiler-plugin to compile the main source sets and the JDK 11 module-info * Adding the Export-Package instruction to felix is required to prevent bnd from thinking META-INF/versions/11 is a package.
|
Hi, I'm playing with this PR and verified the jar produced will load in JDK 6 which works. I'm not clear on how we are supposed to add the multi-version classes though. I tried to add a |
|
The way MRJARs are made, you need to include the class in both source sets. Be careful that they have the same binary interface. So for example, with ThreadUtil: // src/main/java
public final class ThreadUtil {
private ThreadUtil() {}
public static void onSpinWait() {}
}
// src/main/java11
public final class ThreadUtil {
private ThreadUtil() {}
public static void onSpinWait() {
Thread.onSpinWait();
}
} |
|
The CI seems to be failing because it still uses JDK 8, whereas this PR increases the build-time requirement to JDK 11. |
|
I added Errors: |
|
This patch needs to update https://github.com/JCTools/JCTools/blob/master/.travis.yml to use JDK 11 then. |
|
That is interesting. The same build is successful in my environment. I've committed I'm using the following versions on my end and running I've updated the |
|
I can confirm the code builds with |
|
On reflection, I think the right approach here would be a multi-module setup (which is also IDE friendly) with a build step packing the MR jar from all the module. This is outlined here: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html |
|
I've been investigating the issue with the current setup and The downside I see to the Maven multi-module setup and the reason I was reluctant to use it is that it does not allow easily compiling the JPMS module descriptor. To workaround this I will see about using --patch-module, likely using the exec-maven-plugin. Also, it will be the mrjar module that will have to be deployed. Regarding the tests, are you suggesting the existing unit tests in jctools-core/src/test/java be moved to their own module? I must be mistaken. As far I have seen those are almost always kept in the same module and IDEs support them fine. |
Builds a multi-release JAR which enables using features from newer JDK versions while still supporting Java 6. For example, any of the following can be done:
module-infowhich adds support for jlink.Module-Info
This PR also adds
module-infoto the JDK 11 source set - mainly as an example and first step in what can be accomplished with a MR JAR. This is designed first and foremost to create a multi-release jar so that JCTools can leverage features from new JDK versions.Compatibility - OSGI and Others
I made sure to maintain the same OSGI information in the manifest. The felix plugin originally thought that META-INF/versions/11 was a package, but that has been fixed. There is still a minor warning because bnd does not think there should be classes inside META-INF/versions/11. It all still works beside that and OSGI supports MR JARs just fine. Also relevant is bndtools/bnd#2227
Besides OSGI, there were a couple webservers which had incompatibilities with module-info.class being placed inside the root of the jar. To address that, most projects add module-info inside META-INF/versions rather than the jar root (which this PR also does). Plenty of popular libraries have done something like this by now so I do not envision an issue for JCTools either.