Re: [jakartaee-platform-dev] about the status of atinject

[Mark Struberg <struberg@xxxxxxxxxx>]

I now thought for a week about all the pros and cons and specifically went through all the reasons we wanted to amend atinject for CDI.

One of the reason has been to move @Nonbinding to atinject. The reason behind this suggestion was that this is really a big missing feature in atinject. The other change was purely documentation.

But hey, we can easily live with @Nonbinding only being available in CDI. Because if we move atinject from javax.inject to Jakarta.inject then we can also just move those annotations to CDI itself if nobody else is using it.
And docs can also be clarified in CDI if needed. 

What classes are there in atinject?
├── Inject.java		<- has no params, will likely never change
├── Qualifier.java	<- has no params, will likely never change
├── Named.java		<- is just a Qualifier. An important one for CDI but again no params
├── Provider.java	<- subclassed with Instance<T> in CDI, so no need either
├── Scope.java		<- almost unused, in CDI we mainly use @NormalScoped from CDI
└── Singleton.java	<- yikes, duplicates @AplicationScoped, actually know nowbody who uses it

Plus the arguments Tom Schindl already brought to our attention.

So right now I tend to suggest to keep atinject at javax.inject. If we miss features then we will add those in CDI as additional annotations.
But I can live with either ways. We just should find a common understanding about the pros and cons and based on that should make our decision.

LieGre,
strub



> Am 13.05.2019 um 06:31 schrieb Raymond Auge <raymond.auge@xxxxxxxxxxx>:
> 
> +1 for forking
> +1 for keeping it separate
> Modularity is best!
> 
> - Ray
> 
> On Sun, May 12, 2019 at 12:07 PM Lilian BENOIT <lilian.benoit@xxxxxxxxxx> wrote:
> Hi Mark
> 
> Would atinject retain independent spec or do you want include in CDI 
> spec ?
> 
> Personality, i prefer first solution. CDI remain a solution top of DI.
> Other implementation could use DI of JakartaEE (Spring, Guice, ...)
> 
> Before we fork jsr330, couldn't we ask to maintainer of project to 
> transfer jsr330 to JakartaEE ?
> Mailing-list of EG is 
> https://groups.google.com/forum/#!forum/atinject-observer
> 
> 
> Regards,
> Lilian.
> 
> 
> Le 09/05/2019 19:31, Mark Struberg a écrit :
>> Good afternoon!
>> 
>> Had an interesting discussion with David Blevins today.
>> It seems that atinject (JSR-330) is not part of the JavaEE donation
>> from Oracle to the Eclipse Foundation.
>> 
>> This is likely correct as Oracle doesn't own any IP in javax.inject -
>> except the name 'java' in javax.
>> All the rest of the work is owned by the community which drove
>> atinject. That is Bob Lee, Gavin King, Paul Hammant, Jürgen Höller
>> maybe. I was loosely involved on the CDI side of the fence, so I
>> roughly remember the people involved but likely misse some.
>> Main point: ALL the work (javadocs, code, 'spec') is Apache License v2
>> licensed. So it is all perfectly fine to be forked.
>> 
>> Why would we like to fork javax.inject?
>> In the CDI spec we always wanted to further harmonise things. Like
>> bringing the @Nonbinding annotation over to atinject (where it belongs
>> to, also already talked to Spring guys about it). Or enhance the
>> @Scope annotation.
>> 
>> Atinject is a very core spec to JakartaEE. And neither Oracle (they
>> don't touch anything they fully own) nor we (due to 'java' in the
>> packagename) could enhance not a tiny bit in atinject.
>> 
>> So do we also want to move javax.inject to jakarta.inject while we're 
>> at it?
>> 
>> So far I'd strongly favour it.
>> 
>> What do others think?
>> 
>> LieGrue,
>> strub
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)