gradlex-org/java-module-dependencies

Plugin for multi-release JAR building and testing

Closed this issue · 3 comments

chaosflaws commented

I have provided a reproducible sample.

I tried to test a multi-release jar (17 and 21) for behavioral consistency by applying the existing unit tests first to the java 17 sources and then to the combined java 17 + java 21 sources.

The new test suite is called test21, which in turn creates a source set of that name. Because of this, java-module-dependencies complains that the module name - in this case, de.chaosflaws.mrjars.test - does not match the new source set name. (But it's the same sources - once as test and once as test21.)

This could be remedied if test suites could reuse existing source sets. (I opened an issue.) However, I don't expect gradle to address this soon.

Is there something that makes sense to implement here to avoid the problem I am facing?

jjohannes commented

Thanks for providing experiences and feedback on this topic. Doing something in Gradle or a plugin to support this better would be great.

From my understanding, creation of a new test suite and/or source set is the wrong approach to solve this case. These are for "separate (test) components", while I would see the additional Java 21 sources as an addition/variation of an existing component.

I took your example and changed it to a working solution how I would do it here:
https://github.com/jjohannes/gradle-demos/blob/main/multi-release-jars/mr-library/build.gradle

I used the following concepts:

  • Java Toolchains for addressing the different Java versions
  • Source Directory Set for adding Java 21 sources as addition to the main source set. See also my video on the topic: https://youtu.be/74PDtHkS_w4?t=04m13s
    For this, public API is missing, but this is planned. I just talked to Gradle devs about this a few weeks ago. And the public API will probably be what exists already, just stable. The concept itself will stay. See:
  • Adding a new target to the existing test test suite (I.e. adding a new Test task with the same basic configuration as the standard test task). There is no direct API for this at the moment, so you can use tasks.register directly instead. Adding additional targets (i.e. test tasks) to a test suite is something that was planned from the beginning. That's why targets is a collection which always only has one element at the moment. I expect this to be extended in Gradle somewhen in the next months:

To summarize:
If I got what you want to do right, using the setup I have in the demo repo should work for you. It's not directly related to what this – the java-module-dependencies – plugin does. But more a general question of how to build and test MR-Jars with Gradle. I think it would make sense to provide a (small) plugin that makes the setup easier. Probably as a separate GradleX (?) plugin. I'll give it some thought.

On the Gradle core side, I think the issues I linked above should be addressed first. Although a plugin could be provided without changes to Gradle itself.

chaosflaws commented

Sorry for taking so long to respond. I did manage to get the MR-JAR setup to work using your solution. I had to use a bit of exception handling around the toolchains approach, since not all Java versions are available on all my CI executors, but other than that, it was (now) pretty straightforward. Thanks!

I think it would make sense to provide a (small) plugin that makes the setup easier. Probably as a separate GradleX (?) plugin. I'll give it some thought.

As someone who has become quite familiar with Gradle, but is by no means an expert: Your code was certainly helpful to me. At the same time, the topic of Multi-Release Jars does not seem to have caught on much since the feature became available in Java 9. This may be because Gradle does not offer great support for it, but admittedly, other parts of the Java ecosystem do not really provide support for it either. It's hard to say if there's no need or if it's just too hard to set up for the average developer.

The original issue can be considered "resolved".

jjohannes commented

Happy to hear that the solution worked for you @chaosflaws

I put the idea for a MR-Jar plugin on our idea list to revisit it later.