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 <chjohnso...@gmail.com> > 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
