Re: [DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

[Raymond Auge]

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  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é* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

Re: [DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

[Romain Manni-Bucau]

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  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

[DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

[Mark Struberg]

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