Add JPMS module descriptor

[ppkarwasz]

Replaces maven-bundle-plugin with the more up-to-date bnd-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:

org.zeromq.jeromq@0.6.0.SNAPSHOT jar:file:///home/piotr/workspace/jeromq/target/jeromq-0.6.0-SNAPSHOT.jar!/module-info.class
exports org.zeromq
exports org.zeromq.proto
exports org.zeromq.timer
exports org.zeromq.util
exports zmq
exports zmq.io
exports zmq.io.coder
exports zmq.io.coder.raw
exports zmq.io.coder.v1
exports zmq.io.coder.v2
exports zmq.io.mechanism
exports zmq.io.mechanism.curve
exports zmq.io.mechanism.gssapi
exports zmq.io.mechanism.plain
exports zmq.io.net
exports zmq.io.net.ipc
exports zmq.io.net.norm
exports zmq.io.net.pgm
exports zmq.io.net.tcp
exports zmq.io.net.tipc
exports zmq.msg
exports zmq.pipe
exports zmq.poll
exports zmq.socket
exports zmq.socket.clientserver
exports zmq.socket.pipeline
exports zmq.socket.pubsub
exports zmq.socket.radiodish
exports zmq.socket.reqrep
exports zmq.socket.scattergather
exports zmq.util
exports zmq.util.function
requires java.base
requires jnacl static

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 the jnacl dependency is updated, BND should switch to the proposed module name eu.neilalexander.jnacl.

Closes #591.

[fbacchella]

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.

[ppkarwasz]

@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):

• the main and test classes run in the same JPMS module, which means you are not testing encapsulation at all,
• the 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:

• a jeromq module with the main code and tests that require package access,
• a jeromq-its module with tests that just use the public API, running as modules,
• a 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.

[ppkarwasz]

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.