Once the Neon MRI stress (TSC-132) is over, we probably should look at a more permanent solution for the OSGi problems related to Moxy and the javax.json which I battled with in NEUTRON-197. Some options for further discussions:

1. We could revert from the EclipseLink bump from from 2.7.1 to 2.7.3, remove the workarounds, and stay on 2.7.1 forever. That's not so great.

2. The workarounds I put into neutron/parent/pom.xml and into the each odl-neutron-* single feature perhaps could move to odlparent instead of staying in neutron. I don't really like that though, because IMHO it's better for neutron to be able to "control its destiny" and set these version correctly itself; the problem with this is when odlparent next bumps its version of org.eclipse.persistence, it will probably be a mess (bit if anyone has a clear idea how to avoid repeating of org.eclipse.persistence from odlparent in project-neutron-parent, that would address that). More importantly, if we just shuffle ("upstream") that workaround, we would essentially still be eternally stuck on org.glassfish:javax.json version 1.0.4 ...

3. Ideally, we should therefore find a real solution with EclipseLink & javax.json upstreams. What they should really do IMHO is EITHER continue to provide a single JAR including both API & Impl, for those like us under OSGi who were just fine with that, or for javax.json to allow specifying an Impl programmatically instead of via ServiceLoader and/or Class forName, and then for EclipseLink to allow us to set that... that's probably quite a bit of work to drive this end to end from start to completion (issues, contributions, tests, releases, upgrades); my motivation for that is limited.

4. Alternatively, we could perhaps use the latest org.glassfish:javax.json and javax.json:javax.json-api and do some Bundle Buddy Policy something hack to make the Class.forName work after all.

5. We could repackage (the latest version of) javax.json:javax.json-api + org.glassfish:javax.json together into a new combined bundle ourselves? With a Maven POM, not manually; and have our own artifact for this (in like odlparent or infrautils), and override dependencies to use that.