On Mar 19, 2016, at 10:49 AM, Manfred Riem <mnriem(a)gmail.com&gt; wrote: Hi all, I wrote a little blog entry about a CDI wish I have and in essence it comes down to merging JSR-330 into the CDI specification as a sub spec. I realize there is history there, but to me it looks like the best course of action. I had some twitter exchanges about this and some folks are for, some are against. Note I think this is worth exploring as an idea, not something that necessarily needs to be in the current JSR, but definitely something that I think is worth to do at some point (sooner rather than later in my book). What do you think? Thanks! Kind regards, Manfred Riem -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330... Sent from the CDI Development mailing list mailing list archive at Nabble.com. _______________________________________________ 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.

I couldn't agree more ;) Thanks! Kind regards, Manfred Riem > On Mar 19, 2016, at 10:47 AM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: > > I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process. > > BTW, it is really great to see you active in the community! > >> On Mar 19, 2016, at 10:49 AM, Manfred Riem <mnriem(a)gmail.com&gt; wrote: >> >> Hi all, >> >> I wrote a little blog entry about a CDI wish I have and in essence it comes >> down to merging JSR-330 into the CDI specification as a sub spec. I realize >> there is history there, but to me it looks like the best course of action. >> >> I had some twitter exchanges about this and some folks are for, some are >> against. >> >> Note I think this is worth exploring as an idea, not something that >> necessarily needs to be in the current JSR, but definitely something that I >> think is worth to do at some point (sooner rather than later in my book). >> >> What do you think? >> >> Thanks! >> >> Kind regards, >> Manfred Riem >> >> >> >> -- >> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330... >> Sent from the CDI Development mailing list mailing list archive at Nabble.com. >> _______________________________________________ >> 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. _______________________________________________ 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.

Hi Manfred, sorry my replay was a bit out of context since, I was referring to Rezas last mail. As already discussed yesterday, this could proof difficult. Since there are other implementations based on JSR-330, most noticeably spring.

What exactly are we looking to gain from integrating JSR-330? I agree it would be "cleaner", but maybe too much effort for too little gain. If we wanted greater control over those parts, maybe it would be better to move these parts into a separate module for backwards compatibility. Including new CDI owned annotations alongside the separated JSR-330, as and where sensible. Stephan On Sa., 19. März 2016 at 20:40, Manfred Riem <mnriem(a)gmail.com <javascript:_e(%7B%7D,'cvml','mnriem@gmail.com');>> wrote: > Hi Stephan, > > I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter > as it currently > stands. Anything beyond that is beyond the scope of the discussion/wish I > have as that > would then be decided by the combined EG. > > Thanks! > > King regards, > Manfred Riem > > > On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <stephan(a)knitelius.com > <javascript:_e(%7B%7D,'cvml','stephan@knitelius.com');>> wrote: > > If I understand you correctly, you are suggesting to move the JSR-330 > annotations into a separate CDI module/profile, thereby semi-deprecating > these. > > This would essentially open up the possibility of replacing @Named, > etc... with CDI specific annotations. > > Certainly an interesting path to explore. > > Stephan > > > On Sa., 19. März 2016 at 19:27, Manfred Riem <mnriem(a)gmail.com > <javascript:_e(%7B%7D,'cvml','mnriem@gmail.com');>> wrote: > >> I couldn't agree more ;) >> >> Thanks! >> >> Kind regards, >> Manfred Riem >> >> > On Mar 19, 2016, at 10:47 AM, Reza Rahman <reza_rahman(a)lycos.com >> <javascript:_e(%7B%7D,'cvml','reza_rahman@lycos.com');>> wrote: >> > >> > I definitely think it's an idea worth exploring. It will strengthen >> CDI's hand further. It will be great if some of the confusingly redundant >> APIs like @Singleton could be deprecated in the process. >> > >> > BTW, it is really great to see you active in the community! >> > >> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem <mnriem(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','mnriem@gmail.com');>> wrote: >> >> >> >> Hi all, >> >> >> >> I wrote a little blog entry about a CDI wish I have and in essence it >> comes >> >> down to merging JSR-330 into the CDI specification as a sub spec. I >> realize >> >> there is history there, but to me it looks like the best course of >> action. >> >> >> >> I had some twitter exchanges about this and some folks are for, some >> are >> >> against. >> >> >> >> Note I think this is worth exploring as an idea, not something that >> >> necessarily needs to be in the current JSR, but definitely something >> that I >> >> think is worth to do at some point (sooner rather than later in my >> book). >> >> >> >> What do you think? >> >> >> >> Thanks! >> >> >> >> Kind regards, >> >> Manfred Riem >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330... >> >> Sent from the CDI Development mailing list mailing list archive at >> Nabble.com <http://nabble.com>;. >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev(a)lists.jboss.org >> <javascript:_e(%7B%7D,'cvml','cdi-dev@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 >> <javascript:_e(%7B%7D,'cvml','cdi-dev@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 >> <javascript:_e(%7B%7D,'cvml','cdi-dev@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. >> > >

On Mar 19, 2016, at 11:57 AM, aalmiray <aalmiray(a)yahoo.com&gt; wrote: How would this move affect existing implementations, such as Guice, Springframework, Dagger, Afterburner, Griffon, etc? These implementations rely on a tiny core (the small JSR-330 JAR file) and nothing more. What are the foreseeable consequences of such move (as a subspec)? Cheers, Andres -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330... Sent from the CDI Development mailing list mailing list archive at Nabble.com. _______________________________________________ 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.