The fact we sometimes change the default provider can justify we keep it. That said we must also provide the module-info file to stay compliant - and not an automatic module name.
The copyright is also a nice to have which enforces this. Finally I agree keeping osgi control is important for us and eclipse is, let say, not very keen yo do it yet. Le sam. 25 avr. 2020 à 10:43, Mark Struberg <[email protected]> a écrit : > Hi folks! > > JakartaEE moved to the Eclipse Foundation and all the APIs are now > available without much restrictions. > There are 4 potentially problematic issues with the 'official' spec APIs: > > 1.) Most of them are EPLv2 licensed. This is a catB license [1] and > weak-copyleft. That means we MUST add attribution and MUST provide a source > code download. And of course not only we need to do this, but reciprocallly > also all the downstream consumers and users. > > 2.) Our very own geronimo spec APIs used to have really great OSGi > integration. The official API jars not so much. Some of them have no OSGi > support at all. Did anyone look at the new official spec APIs? Can they be > used in OSGi environments? I'm not an OSGi person myself, so I need others > to join into this discussion. > > 3.) Java8 support. Our own spec APIs mostly do not have module > information. I just recently added this via MANIFEST.MF. The official spec > API jars mostly use a module-info.class file. While this is technically > preferable, it often bombs up with older low level bytecode manipulation > libraries. The cause is that module-info.class must at least be a Java9 > class file. So it's not really compatible with Java8. This doesn't happen > that often - but I saw it happening. Is this really a problem? Or should we > move to Java11 with JakartaEE anyway? > > 4.) When developing a new spec we cannot easily take the EPLv2 licensed > sources over and modify them ourselves. We are bound to whatever Eclipse > publishes as snapshot. Something to consider... > > Of course the upside of using the official API jars are: > * we do not need to do any bytecode compat signature checks anymore. > * the JavaDoc is MUCH better obviously > > Anything I missed? > > LieGrue, > strub
