I am in the same boat, this sounds like it would quickly become a maintenance headache. We don't have the time or people to maintain more than one branch, particularly if that branch would be a significant refactor of the code
I am afraid that JPMS is going to kill Java open source efforts in the same way that .Net profiles killed .Net open source. It seems to add a lot of complexity for developers, requires the entire ecosystem to buy in before it is truly usable i.e. even if we refactor our modules are all our many dependencies compliant, and doesn't seem like it adds much value to end users at least from my perspective. Rob On 27/04/2018, 14:10, "ajs6f" <[email protected]> wrote: I'm not sure how this new branch is supposed to work. If it "just contains modules compliant with the JPMS and that is tested for JDK9+" but the current (Maven) modules don't have a one-to-one correspondence with usable JPMS modules, where are the "modules" for this new branch coming from? Are you suggesting decomposing the entire package structure of the codebase and recomposing it in a branch? On what basis would packages be grouped? ajs6f > On Apr 26, 2018, at 2:58 PM, Christopher Johnson <[email protected]> wrote: > > In reference to a recent PR (https://github.com/apache/jena/pull/401), I am > seeking input on a process to move forward towards JDK9+ (and JPMS) support > in Jena. As consumers of jena apis, the applications that I am developing > will require JPMS support going forward, so this is an important issue for > my use case. > > What I have noticed is that there will be breaking changes required to > structure the code in a way that meets the JPMS "non-interference" > specification.[1] A specific problem occurs when a module does not contain > a single root package (which is a typical condition in several jena > modules). This results in an "ambiguous module reference" error. To > resolve this ambiguity may require considerable refactoring (e.g. moving > org.apache.jena.riot to org.apache.jena.arq.riot). I surmise that it is > not possible to make these changes and maintain compatibility for existing > consumers > > What I would like to propose is a new branch that just contains modules > compliant with the JPMS and that is tested for JDK9+. Artifacts produced > from this branch could be distinguished from master artifacts with an > appropriate appendix. > > Thank you for your consideration, > Christopher Johnson > Scientific Associate > Universitätsbibliothek Leipzig > > [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference
