Hi, JPMS is certainly a major change. I believe that it offers enormous value to a codebase with strong encapsulation and as such it is similar to OSGI. The benefits of OSGI are well known, though the implementations are fraught with complexity. Comparatively, JPMS is relatively simple.
Retrofitting a robust platform like Jena is without question a big challenge. JPMS exposes legacy APIs, so aging dependencies (like log4j 1.x and junit4) will also need to be updated. Maintaining separate branches for the long term is indeed a headache. The branch approach provides a short term path for learning how to make the break in a major version. Ultimately, it is a question of compliance and standardization. Does Jena want to "buy into" a new global standard or risk being marginalized in the future? Regarding the composition of the branch, it could start "small". Perhaps just with arq, base, and core. These would be the root packages for those modules and the ambiguous packages could be moved under them naturally. The testing infrastructure may need a different approach (i.e. using JUnit5). Christopher On Fri, 27 Apr 2018, 15:38 Rob Vesse, <[email protected]> wrote: > 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 > > > > > > >
