Creating multi release jar #110
Conversation
|
Almost forgot an important note: I had to update the bnd plugin, and this forced a dependency on JDK 17 for the build. So, now people opening the project will require to set the Gradle JVM (or |
… different versions of javac. Note: bnd had to be updated to add support for this, and the new bnd requires JDK 17. So, now the minimum JDK required to run the build is 17. Also rat was updated and new xalan dependencies were added (this was forced on us by the bnd update).
kelemen
force-pushed
the
multi-release-jar
branch
from
7b1dc7b
to
7f935b5
Compare
…other tests are kept as well to avoid complications and to allow for faster test runs when just checking a particular class (or source set).
|
Actually, I have found a not too complicated way to add test tasks depending on the jar instead. Also, they are not added per source set where tests are enabled, because I have realized that they might have conflicting dependencies. A small issue with this solution is that now the tests are run twice. While inefficient, it has a minor benefit: The failures due to the effect of the multi release jar can be separated from the test failures. Also, locally it is usually better to not run against the jar, because it is faster. |
The tests tasks were not touched at all. So, they do not depend on the jar. If such tasks are needed, then I think new test tasks should be added as opposed adjusting the current test tasks. This is to avoid confusing IDEs (and a considerable complications), also it would make more sense conceptually that then there would be a combined test task depending on the jar for each java version (and the tasks wouldn't be directly tied to source sets).