Re: [CDI40] how to tackle the jakarta 10 APIs?

[Romain Manni-Bucau]

Le mer. 23 nov. 2022 à 11:18, Mark Struberg  a écrit :

>
> Not from a spec standpoint, it is the opposite, full is optional but is
> based on lite (once again not saying it is good).
>
>
>
> From the wording of the spec. But this is totally inside out.
>

You mean at
https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#_cdi_full
?
> CDI Full contains all the functionality defined in CDI Lite and adds some
additional features such as specialization, decorators, session scope or
conversation scope. Some of these concepts were briefly mentioned in the
previous CDI Lite chapter and this section of specification defines them in
depth.


> Technically you can have 'CDI classic' without any of the 'CDI-light'
> (which adds tons of stuff to 'classic').
> And this is what we should do.
>

Technically you can have CDI without extensions too, I don't think doing
something unrelated to the spec is good for users even if I deplore the
path the spec takes.


>
> Legally we are now fine to consume jakarta artifacts
>
>
> Yes, as long as they are really ALv2 (clearly) or EPLv2.0 (needs some
> attribution IF we also bundle those jars...) and not their 'Jakarta spec
> license'.
> But that seems to be EPLv2 as far as I've looked through a bunch of spec
> api jars.
>

EPLv2 is "weak copyleft" so guess it is fine (
https://www.apache.org/legal/resolved.html)


>
> LieGrue,
> strub
>
> Am 23.11.2022 um 11:02 schrieb Romain Manni-Bucau :
>
>
>
>
> Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev <
> dev@geronimo.apache.org> a écrit :
>
>> As written over at the OWB list:
>>
>> I intend only to update OWB to the jakarta package names plus implement
>> the core changes.
>>
>> All that 'cdi-light' stuff (which is imo rather broken) is technically
>> optional and can also get implemented as a plugin.
>>
>
> Not from a spec standpoint, it is the opposite, full is optional but is
> based on lite (once again not saying it is good).
>
>
>> I just don't want to have all those tons of new classes around nobody
>> needs if not running on Quarkus.
>>
>
> Well, if you look the way the spec was written, then you need it.
> Or said otherwise, if you think this way you must make all the extension
> API optional as well and get "cdi-runtime-api", "cdi-lite", "cdi-full" or
> something like that.
> Once again I don't think we can fight much there so guess we should just
> get it as in the spec, optionally we can get as the spec intend lite bundle
> and full bundle but not the other way around.
>
>
>>
>> What about the other spec APIs we still need? use the Eclipse one (EPL +
>> spec)? What legal consequences does this have in comparison to updating our
>> own packages? It's mostly just package renames for now anyway.
>>
>
> Legally we are now fine to consumme jakarta artifacts so last time we
> discussed it we decided to keep our "forks" for OSGi but guess we can
> discuss with karaf/smix projects to drop it and let them do it if you want
> to stop doing spec jars.
> Just want we clearly document it for users on our website.
>
>
>>
>> LieGrue,
>> strub
>>
>> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau > >:
>>
>> Hi,
>>
>> Well, I guess the OSGi stuff is still a good justification to roll our
>> own even if they didnt catch up yet jakarta - think they will anyway and
>> owb runs in any case.
>>
>> On the flavor we can do a lite-free module but since standard version
>> assumes lite extensions are ran as part of the runtime - strictly speaking
>> they say runtime or build or anything but spec only defines a runtime so it
>> is literally at runtime - I guess owb still needs to impl it and I don't
>> like much the idea to implement a subpart of the minimum requirement of the
>> spec - never said I think what they did is ok, it is fully wrong but it is
>> what we have today and fighting against the spec is never good while using
>> its API IMHO.
>>
>> So concretely I would just do a standard bundle for OSGi stuff and be it.
>> We need to see what we do at OWB but fear we just back lite by a full
>> extensions at some point, at least in extension mode.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev <
>> dev@geronimo.apache.org> a écrit :
>>
>>> Hi!
>>>
>>> How do we want to approach the CDI-4.0 api?
>>> I don't want to just use the official API as it is bloated with the 'CDI
>>> light' stuff.
>>> So there is good reason to just keep our own version - even if it is
>>> just a shaded/spit of the official one.
>>>
>>> What about the others? Do we still want to roll our own or also take the
>>> official ones?
>>> What is the benefit of one approach over the other?

Re: [CDI40] how to tackle the jakarta 10 APIs?

[Mark Struberg via dev]

> Not from a spec standpoint, it is the opposite, full is optional but is based 
> on lite (once again not saying it is good).
>  

From the wording of the spec. But this is totally inside out.
Technically you can have 'CDI classic' without any of the 'CDI-light' (which 
adds tons of stuff to 'classic').
And this is what we should do. 

> Legally we are now fine to consume jakarta artifacts 

Yes, as long as they are really ALv2 (clearly) or EPLv2.0 (needs some 
attribution IF we also bundle those jars...) and not their 'Jakarta spec 
license'.
But that seems to be EPLv2 as far as I've looked through a bunch of spec api 
jars.

LieGrue,
strub

> Am 23.11.2022 um 11:02 schrieb Romain Manni-Bucau :
> 
> 
> 
> 
> Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev  > a écrit :
>> As written over at the OWB list:
>> 
>> I intend only to update OWB to the jakarta package names plus implement the 
>> core changes.
>> 
>> All that 'cdi-light' stuff (which is imo rather broken) is technically 
>> optional and can also get implemented as a plugin.
> 
> Not from a spec standpoint, it is the opposite, full is optional but is based 
> on lite (once again not saying it is good).
>  
>> I just don't want to have all those tons of new classes around nobody needs 
>> if not running on Quarkus.
> 
> Well, if you look the way the spec was written, then you need it.
> Or said otherwise, if you think this way you must make all the extension API 
> optional as well and get "cdi-runtime-api", "cdi-lite", "cdi-full" or 
> something like that.
> Once again I don't think we can fight much there so guess we should just get 
> it as in the spec, optionally we can get as the spec intend lite bundle and 
> full bundle but not the other way around.
>  
>> 
>> What about the other spec APIs we still need? use the Eclipse one (EPL + 
>> spec)? What legal consequences does this have in comparison to updating our 
>> own packages? It's mostly just package renames for now anyway.
> 
> Legally we are now fine to consumme jakarta artifacts so last time we 
> discussed it we decided to keep our "forks" for OSGi but guess we can discuss 
> with karaf/smix projects to drop it and let them do it if you want to stop 
> doing spec jars.
> Just want we clearly document it for users on our website.
>  
>> 
>> LieGrue,
>> strub
>> 
>>> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau >> >:
>>> 
>>> Hi,
>>> 
>>> Well, I guess the OSGi stuff is still a good justification to roll our own 
>>> even if they didnt catch up yet jakarta - think they will anyway and owb 
>>> runs in any case.
>>> 
>>> On the flavor we can do a lite-free module but since standard version 
>>> assumes lite extensions are ran as part of the runtime - strictly speaking 
>>> they say runtime or build or anything but spec only defines a runtime so it 
>>> is literally at runtime - I guess owb still needs to impl it and I don't 
>>> like much the idea to implement a subpart of the minimum requirement of the 
>>> spec - never said I think what they did is ok, it is fully wrong but it is 
>>> what we have today and fighting against the spec is never good while using 
>>> its API IMHO.
>>> 
>>> So concretely I would just do a standard bundle for OSGi stuff and be it.
>>> We need to see what we do at OWB but fear we just back lite by a full 
>>> extensions at some point, at least in extension mode.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog 
>>>  | Old Blog 
>>>  | Github 
>>>  | LinkedIn 
>>>  | Book 
>>> 
>>> 
>>> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev 
>>> mailto:dev@geronimo.apache.org>> a écrit :
 Hi!
 
 How do we want to approach the CDI-4.0 api?
 I don't want to just use the official API as it is bloated with the 'CDI 
 light' stuff.
 So there is good reason to just keep our own version - even if it is just 
 a shaded/spit of the official one.
 
 What about the others? Do we still want to roll our own or also take the 
 official ones?
 What is the benefit of one approach over the other?
 
 let's discuss!
 
 LieGrue,
 strub
 
>> 

Re: [CDI40] how to tackle the jakarta 10 APIs?

[Romain Manni-Bucau]

Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev 
a écrit :

> As written over at the OWB list:
>
> I intend only to update OWB to the jakarta package names plus implement
> the core changes.
>
> All that 'cdi-light' stuff (which is imo rather broken) is technically
> optional and can also get implemented as a plugin.
>

Not from a spec standpoint, it is the opposite, full is optional but is
based on lite (once again not saying it is good).


> I just don't want to have all those tons of new classes around nobody
> needs if not running on Quarkus.
>

Well, if you look the way the spec was written, then you need it.
Or said otherwise, if you think this way you must make all the extension
API optional as well and get "cdi-runtime-api", "cdi-lite", "cdi-full" or
something like that.
Once again I don't think we can fight much there so guess we should just
get it as in the spec, optionally we can get as the spec intend lite bundle
and full bundle but not the other way around.


>
> What about the other spec APIs we still need? use the Eclipse one (EPL +
> spec)? What legal consequences does this have in comparison to updating our
> own packages? It's mostly just package renames for now anyway.
>

Legally we are now fine to consumme jakarta artifacts so last time we
discussed it we decided to keep our "forks" for OSGi but guess we can
discuss with karaf/smix projects to drop it and let them do it if you want
to stop doing spec jars.
Just want we clearly document it for users on our website.


>
> LieGrue,
> strub
>
> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau :
>
> Hi,
>
> Well, I guess the OSGi stuff is still a good justification to roll our own
> even if they didnt catch up yet jakarta - think they will anyway and owb
> runs in any case.
>
> On the flavor we can do a lite-free module but since standard version
> assumes lite extensions are ran as part of the runtime - strictly speaking
> they say runtime or build or anything but spec only defines a runtime so it
> is literally at runtime - I guess owb still needs to impl it and I don't
> like much the idea to implement a subpart of the minimum requirement of the
> spec - never said I think what they did is ok, it is fully wrong but it is
> what we have today and fighting against the spec is never good while using
> its API IMHO.
>
> So concretely I would just do a standard bundle for OSGi stuff and be it.
> We need to see what we do at OWB but fear we just back lite by a full
> extensions at some point, at least in extension mode.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev <
> dev@geronimo.apache.org> a écrit :
>
>> Hi!
>>
>> How do we want to approach the CDI-4.0 api?
>> I don't want to just use the official API as it is bloated with the 'CDI
>> light' stuff.
>> So there is good reason to just keep our own version - even if it is just
>> a shaded/spit of the official one.
>>
>> What about the others? Do we still want to roll our own or also take the
>> official ones?
>> What is the benefit of one approach over the other?
>>
>> let's discuss!
>>
>> LieGrue,
>> strub
>>
>>
>

Re: [CDI40] how to tackle the jakarta 10 APIs?

[Mark Struberg via dev]

As written over at the OWB list:

I intend only to update OWB to the jakarta package names plus implement the 
core changes.

All that 'cdi-light' stuff (which is imo rather broken) is technically optional 
and can also get implemented as a plugin.
I just don't want to have all those tons of new classes around nobody needs if 
not running on Quarkus.

What about the other spec APIs we still need? use the Eclipse one (EPL + spec)? 
What legal consequences does this have in comparison to updating our own 
packages? It's mostly just package renames for now anyway.

LieGrue,
strub

> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau :
> 
> Hi,
> 
> Well, I guess the OSGi stuff is still a good justification to roll our own 
> even if they didnt catch up yet jakarta - think they will anyway and owb runs 
> in any case.
> 
> On the flavor we can do a lite-free module but since standard version assumes 
> lite extensions are ran as part of the runtime - strictly speaking they say 
> runtime or build or anything but spec only defines a runtime so it is 
> literally at runtime - I guess owb still needs to impl it and I don't like 
> much the idea to implement a subpart of the minimum requirement of the spec - 
> never said I think what they did is ok, it is fully wrong but it is what we 
> have today and fighting against the spec is never good while using its API 
> IMHO.
> 
> So concretely I would just do a standard bundle for OSGi stuff and be it.
> We need to see what we do at OWB but fear we just back lite by a full 
> extensions at some point, at least in extension mode.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 
> 
> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev  > a écrit :
>> Hi!
>> 
>> How do we want to approach the CDI-4.0 api?
>> I don't want to just use the official API as it is bloated with the 'CDI 
>> light' stuff.
>> So there is good reason to just keep our own version - even if it is just a 
>> shaded/spit of the official one.
>> 
>> What about the others? Do we still want to roll our own or also take the 
>> official ones?
>> What is the benefit of one approach over the other?
>> 
>> let's discuss!
>> 
>> LieGrue,
>> strub
>> 

Re: [CDI40] how to tackle the jakarta 10 APIs?

[Romain Manni-Bucau]

Hi,

Well, I guess the OSGi stuff is still a good justification to roll our own
even if they didnt catch up yet jakarta - think they will anyway and owb
runs in any case.

On the flavor we can do a lite-free module but since standard version
assumes lite extensions are ran as part of the runtime - strictly speaking
they say runtime or build or anything but spec only defines a runtime so it
is literally at runtime - I guess owb still needs to impl it and I don't
like much the idea to implement a subpart of the minimum requirement of the
spec - never said I think what they did is ok, it is fully wrong but it is
what we have today and fighting against the spec is never good while using
its API IMHO.

So concretely I would just do a standard bundle for OSGi stuff and be it.
We need to see what we do at OWB but fear we just back lite by a full
extensions at some point, at least in extension mode.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev 
a écrit :

> Hi!
>
> How do we want to approach the CDI-4.0 api?
> I don't want to just use the official API as it is bloated with the 'CDI
> light' stuff.
> So there is good reason to just keep our own version - even if it is just
> a shaded/spit of the official one.
>
> What about the others? Do we still want to roll our own or also take the
> official ones?
> What is the benefit of one approach over the other?
>
> let's discuss!
>
> LieGrue,
> strub
>
>

[CDI40] how to tackle the jakarta 10 APIs?

[Mark Struberg via dev]

Hi!

How do we want to approach the CDI-4.0 api?
I don't want to just use the official API as it is bloated with the 'CDI light' 
stuff.
So there is good reason to just keep our own version - even if it is just a 
shaded/spit of the official one.

What about the others? Do we still want to roll our own or also take the 
official ones?
What is the benefit of one approach over the other?

let's discuss!

LieGrue,
strub