[cdi-dev] Time to start working on CDI lite

Sun Aug 30 12:15:53 EDT 2015

2015-08-30 18:09 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:

> For me, a Light version of CDI is clearly the features number. That's why
> I don't see events in it.
>
> For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring
> has @Bean, then it's because 330 lakes this functionality.
>
>
Agree on the need of this feature that said I understand 330 as some nice
set of common annotations but used by everybody differently - @Inject in
spring is different from @Inject in CDI or Tapestry typically.

About events i think they are common enough - in particular in term of
maintenance - to be there by default and size they imply is not important
enugh to not get them onboard IMO.

Now I see we dont agree on what "Lite" can mean - thought it was removing
features to be lighter in size - so we should maybe vote to decide the
actual target and just go ahead on it.

Do you share this point?

> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> > wrote:
>
>> Lite can have several definition, let's try to list them up if it can
>> help:
>>
>> - binary size: for me until 3M for an app it is "Lite"
>> - features number: the whole IoC set of feature is light since you almost
>> always need it, it means you can do lighter but it wouldnt be used - check
>> spring, who uses only spring-ioc and not context or more?
>> - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>>
>> So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> implementations so seems the fight is not on the right side to me.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com
>> >:
>>
>>> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>>> forked 330 because he found CDI was doing too much  ;o)
>>>
>>> For me, "CDI Lite" was just basic dependency injection. The fact that
>>> CDI can now run on SE (like JPA....), is good... but for me it has nothing
>>> to do with Light : it's the entire thing that can bootstrap in SE. Good.
>>>
>>> So what is Lite for you guys ?
>>>
>>> Antonio
>>>
>>> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>>> rmannibucau at gmail.com> wrote:
>>>
>>>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>>>>
>>>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>>>>> with EJB, but never implemented properly (most implementations that support
>>>>> EJB-lite actually support the entire thing, except for deprecated stuff).
>>>>>
>>>>>
>>>> +1, most of CDI is basic and quickly any light version will miss events
>>>> or other thing - in particular in maintaining micro services from
>>>> experience. Size of an implementation can easily be < 1M so not sure it
>>>> would bring anything. Only important point is what Antoine started to do ie
>>>> ensuring EE and SE parts are clearly identified and split in the spec.
>>>>
>>>>
>>>>> I think if we define SE properly we won't have a need for this.
>>>>>
>>>>> John
>>>>>
>>>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>>>>> antonio.goncalves at gmail.com> wrote:
>>>>>
>>>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>>>>>> about events ?
>>>>>>
>>>>>> I'm in favor of a "fatter" 330 that would have :
>>>>>>
>>>>>>    - @Inject : already there
>>>>>>    - @Qualifier : already there
>>>>>>    -
>>>>>> *Producers and disposers *
>>>>>>    -
>>>>>> *Programatic lookup *
>>>>>>    - *Java SE Bootstrap*
>>>>>>
>>>>>> When you say "*The goal here is not to propose a new EE profile but
>>>>>> a subspec*", 330 could already be seen as a subspec. If you put
>>>>>> events apparts, what would be missing in this list in your point of view ?
>>>>>> And what obstacles do you see in archieving this ?
>>>>>>
>>>>>> To boostrap CDI we have a CDIProvider, why not having an
>>>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>>>>>> InjectionProvider, so it bootstraps the all thing) ?
>>>>>>
>>>>>> Antonio
>>>>>>
>>>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>>>>>> antoine at sabot-durand.net> wrote:
>>>>>>
>>>>>>> Yes Arjan, I think it's the first reason. We really should work with
>>>>>>> them to understand what should be added to CDI 2.0 to have it as a first
>>>>>>> citizen DI in their spec.
>>>>>>>
>>>>>>> Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>>>>> <antonio.goncalves at gmail.com> wrote:
>>>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>>>>>>>> (back in EE6),
>>>>>>>> > and their answer for not adopting CDI was "too heavy".
>>>>>>>>
>>>>>>>> I can't find an exact reference anymore, but I somewhat remember
>>>>>>>> that
>>>>>>>> one of the reasons was also simply that CDI as a general solution
>>>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>>>>>>>> all
>>>>>>>> the work for their own DI solution already done.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Antonio Goncalves
>>>>>> Software architect, Java Champion and Pluralsight author
>>>>>>
>>>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>>>>> <http://twitter.com/agoncal> | LinkedIn
>>>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>>>>>>  | Paris JUG <http://www.parisjug.org> | Devoxx France
>>>>>> <http://www.devoxx.fr>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider licenses
>>>>>> the code under the Apache License, Version 2 (
>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>> intellectual property rights inherent in such information.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses
>>>>> the code under the Apache License, Version 2 (
>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual property rights inherent in such information.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>
>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/bdee541f/attachment.html 