Github user christopher-johnson commented on the issue:
https://github.com/apache/jena/pull/401
a quick note here about the prospect of further restructuring to support
jpms. I have learned today that if a module (e.g. `org.apache.jena.arq`) does
not contain a single top level package this creates an "ambiguous module". The
expectation is that the module contains a hierarchy of packages and this does
not exist in the primary jena library modules, It is possible for the top
package to not contain any classes, but the `module-info.java` then must
explictly export every subpackage it wants to make public. With a new package
hierarchy, it does not seem possible to maintain compatibility with existing
implementations _and_ support modules with jena master. One possibility might
be to create a new branch and produce distinct artifacts that could be used
downstream. It could also be used for testing and making changes to support
the new jdk methods without impacting LTS. btw, I have noticed in running the
tests that there are a few issues due to jdk changes (`java.nio.Byt
eBuffer`, for example). This might be a question for the dev list.
---
