2015-08-30 18:09 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)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(a)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(a)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(a)gmail.com> wrote:
>>
>>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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(a)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(a)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(a)gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>>>> <antonio.goncalves(a)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(a)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(a)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>