Should Moxy be forked to its own project?

[jgrassel]

I wanted to open a discussion regarding Moxy. It's part of the Eclipselink project, but it seems strange for a JPA provider implementation project to also contain a JAXB provider implementation project. Wouldn't it make more sense to move Moxy to its own github project, and just reference it as a dependency?

[patric-r]

+1 I always wondered about this.

[lukasj]

well, there are more to this. If one looks at the content of the EclipseLink, there are components which do not make much sense for pure-jpa implementation - SDO is just another one, DBWS can be seen as next, then there are some utilities like package rename or signature tester - btw yasson was initially part of eclipselink project too. Hermes (JPQL parser and tooling) as well as repackaged asm could probably live on their own as well (like oracleddlparser and workbench). The big problem of this would be to keep everything up to date and working together - ie workbench has not been updated for some time already....

The problematic part is that MOXy as well as JPA impl do depend on o.e.p.core module, there is NO direct dependency between MOXY and JPA impl these days; there is just that dependency both have on the core which is non-trivial to remove (mostly because one needs to handle orm/persistence xml descriptors in JPA and does not want to depend/use whole MOXy) - btw historically XML was seen as "just another storage" by EL and making existing code JAXB compliant was low hanging fruit to get....

Given where we are, I'm thinking more about just dropping everything but core, moxy and jpa going forward and focus on JDK 11/17 with either eclipselink 4.0 or sth like eclipselink-light (since 3.0 will have to stay on JDK 8 for some time) - both could be just a branch in this repo to allow us easy backports of fixes... Would sth like be an option for you?