As someone who has fought for better OSGi support in the MP spec APIs I can say that this has proven difficult and largely without success.
Le sam. 25 avr. 2020 à 10:43, Mark Struberg <strub...@yahoo.de> a écrit : > 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. >> > This is the weakest part of my knowledge about it, but I cannot disagree. > >> 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. >> > I can attest that the spec jars *cannot be used together in a pure OSGi environment without modification*! You don't have to look further than the package imports of the specs as a whole to see that they are disjointed in terms of the import requirements. This is only the first part of the issue. > >> 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? >> > With modern tooling, Geronimo can continue building on Java8 to remain compatible, while also generating a Java9 module-info.java (even while still using the maven-bundle-plugin) if we choose. Bnd since 4.3.0 can write Java9 module info while running on Java8. > >> 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... >> > Since most of the changes in order to properly support OSGi don't necessarily involve code changes, and are mostly about generating proper bundle metadata I think building from the original sources isn't that hard and what I've been mostly doing since the beginning. > >> 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 >> > Agreed! So, I would support Apache rolling our own. - Ray > >> Anything I missed? >> >> LieGrue, >> strub > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
