Closed ppkarwasz closed 8 months ago
The problem I have with JPMS is that that there is no way to test it. I checked, your patch indeed only add a module-info.class
in the resulting jar. But does it contains the good informations ? I don’t know any way to be sure. Even the OSGi part is quite obscure to me.
@fbacchella,
Thank you for merging this PR.
Sorry I didn't have time to answer you remarks. Basically you are right: I don't know a good way to test JPMS modules either. Maven Surefire and Failsafe have some basic support for that: if they detect a module-info.class
file in target/classes
(Surefire) or the generated JAR (Failsafe), they run the tests on the module path instead of the class path.
When running on the module path, there are two scenarios (IIRC that depends if target/test-classes
have a module descriptor or not):
main
and test
classes run in the same JPMS module, which means you are not testing encapsulation at all,main
and test
classes run in different modules, which means the tests must use a different package than the main classes and you can not test classes/methods with package access.I don't know an ideal solution to this conundrum. As far as I can tell the Maven Compiler Plugin only supports two source file trees (main
and test
). A workaround to this limitation would be to have multiple Maven modules for each kind of test:
jeromq
module with the main code and tests that require package access,jeromq-its
module with tests that just use the public API, running as modules,jeromq-osgi-test
module with tests in an OSGi environment (cf. log4j-osgi-test).Remark: in your case the module descriptor in quite safe. It exports all the packages contained in jeromq
, so users should not have a problem with that. The only thing that is worth checking is whether you can compile and run a program without the optional jnacl
library.
The jeromq
tests are actually pretty nice, when it comes to repackaging. I managed to move all but 18 of them to different packages (cf. ppkarwasz/move-tests branch).
Therefore you might move them to a different Maven module and run them on the module path, which means full-blown JPMS testing.
Replaces
maven-bundle-plugin
with the more up-to-datebnd-maven-plugin
and configures it to generate a JPMS module descriptor besides the OSGi descriptor. The descriptor can be generated even using JDK 8 (cf. documentation).Decompiling the generated descriptor we obtain:
The generated descriptor contains one filebased module name (
jnacl
), but it is an optional module, so this should not cause problems.I submitted a similar PR to
jnacl
(neilalexander/jnacl#24). If that PR is accepted and thejnacl
dependency is updated, BND should switch to the proposed module nameeu.neilalexander.jnacl
.Closes #591.