On 15 Apr 2015, at 13:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: Hi all, Rethinking of this task and reading the feedback on this, I really think we should go step by step on this splitting. What I have produced here is a full extraction of EJB in the spec to put it in EE part.

There are still Java EE references in core with EL, JSF, Servlet.

The more problematic part is the Contexts chapter: hard to remove servlet ref without rewriting all... And yes, I did some rewording that could be no very nice. In some places I replaces "Managed Beans or Session Beans" by the generic term "bean”.

Java EE component was replaced by component (yes, I'm not sure it is very meaningful)

In the EE part, I added changed all "session bean" occurrences by "EJB session bean”.

The step I see are: 0) Validate that we're all ok with the principle of splitting 1) validate that all EJB references are removed from core 2) Correct bad terminology that I introduced And then we should continue the splitting by rewriting the contexts chapter and EL references in Core.

Antoine _______________________________________________ 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.

Antoine, I've lost track of this topic. Is the document somewhere ? Can we easily see the diffs ? Managed Beans are already confusing.... turning it to "bean" can be even more confusing. Antonio On Wed, Apr 15, 2015 at 5:08 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > > On 15 Apr 2015, at 13:31, Antoine Sabot-Durand < > antoine(a)sabot-durand.net&gt; wrote: > > > > Hi all, > > > > Rethinking of this task and reading the feedback on this, I really > think we should go step by step on this splitting. > > > > What I have produced here is a full extraction of EJB in the spec to > put it in EE part. > > Yes, this is a great start. > > > There are still Java EE references in core with EL, JSF, Servlet. > > I’m least worried about EL, most about JSF and Serlet. > > > > > The more problematic part is the Contexts chapter: hard to remove > servlet ref without rewriting all... > > > > And yes, I did some rewording that could be no very nice. > > > > In some places I replaces "Managed Beans or Session Beans" by the > generic term "bean”. > > This is definitely not ok, as you expanded the scope of the sentence to > include built-in beans, producer methods, producer fields, and custom > beans. I would suggest providing list of these changes, so we can review > each one. > > > Java EE component was replaced by component (yes, I'm not sure it is > very meaningful) > > I also think this is problematic. A Java EE component is a specific > thing. I would suggest providing list of these changes, so we can review > each one. > > > > > In the EE part, I added changed all "session bean" occurrences by "EJB > session bean”. > > Ok, I don’t think this is a problem. > > > > > The step I see are: > > > > 0) Validate that we're all ok with the principle of splitting > > 1) validate that all EJB references are removed from core > > 2) Correct bad terminology that I introduced > > > > And then we should continue the splitting by rewriting the contexts > chapter and EL references in Core. > > +1 > > > > > Antoine > > _______________________________________________ > > 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>

On 16 Apr 2015, at 08:59, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: > > Le 15 avr. 2015 à 17:08, Pete Muir <pmuir(a)redhat.com&gt; a écrit : > > >> On 15 Apr 2015, at 13:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: >> >> Hi all, >> >> Rethinking of this task and reading the feedback on this, I really think we should go step by step on this splitting. >> >> What I have produced here is a full extraction of EJB in the spec to put it in EE part. > > Yes, this is a great start. > >> There are still Java EE references in core with EL, JSF, Servlet. > > I’m least worried about EL, most about JSF and Serlet. I’m not sure about JSF. Servlet is still here mainly because of contexts. As we'll probably change a few things in context (if we add context control for instance) perhaps and complete review of chapter 6 (scopes and context) will be necessary…

> >> >> The more problematic part is the Contexts chapter: hard to remove servlet ref without rewriting all... >> >> And yes, I did some rewording that could be no very nice. >> >> In some places I replaces "Managed Beans or Session Beans" by the generic term "bean”. > > This is definitely not ok, as you expanded the scope of the sentence to include built-in beans, producer methods, producer fields, and custom beans. I would suggest providing list of these changes, so we can review each one. Agree, on the paper that looks messy. I did it when I thought that the rules applied to all kind of beans,

for others places I had to remove "session bean” mention (letting only managed bean) and recreate a similar section in EE part stating that rules in section foo of core was also valid for session beans.

I’ll create a list of these generic change since it’ll be easier to check if I didn’t made a mistake. > >> Java EE component was replaced by component (yes, I'm not sure it is very meaningful) > > I also think this is problematic. A Java EE component is a specific thing. I would suggest providing list of these changes, so we can review each one. We have to find a new terminology. I’m a bit clueless her. Will list the places as well.

> >> >> In the EE part, I added changed all "session bean" occurrences by "EJB session bean”. > > Ok, I don’t think this is a problem. We have a ticket staying that we should clarify the term beans in the spec. > >> >> The step I see are: >> >> 0) Validate that we're all ok with the principle of splitting >> 1) validate that all EJB references are removed from core >> 2) Correct bad terminology that I introduced >> >> And then we should continue the splitting by rewriting the contexts chapter and EL references in Core. > > +1 I guess that everybody is ok with 0 by now. 1 is in process and shouldn’t be too hard, 2 is the trickiest one. I’ll produce this list by the end of the week so we can discuss of each occurrences. > >> >> Antoine >> _______________________________________________ >> 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.

On Thursday, 16 April 2015, 14:03, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: > Hi, On Thu, Apr 16, 2015 at 9:25 AM, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: > Managed Beans are already confusing.... turning it to "bean" can be even > more confusing. And what about the confusion that a "factory" for a type is also called Bean? (Bean<T>) Kind regards, Arjan Tijms > > Antonio > > On Wed, Apr 15, 2015 at 5:08 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> >> >> > On 15 Apr 2015, at 13:31, Antoine Sabot-Durand >> > <antoine(a)sabot-durand.net&gt; wrote: >> > >> > Hi all, >> > >> > Rethinking of this task and reading the feedback on this, I really think >> > we should go step by step on this splitting. >> > >> > What I have produced here is a full extraction of EJB in the spec to put >> > it in EE part. >> >> Yes, this is a great start. >> >> > There are still Java EE references in core with EL, JSF, Servlet. >> >> I’m least worried about EL, most about JSF and Serlet. >> >> > >> > The more problematic part is the Contexts chapter: hard to remove >> > servlet ref without rewriting all... >> > >> > And yes, I did some rewording that could be no very nice. >> > >> > In some places I replaces "Managed Beans or Session Beans" by the >> > generic term "bean”. >> >> This is definitely not ok, as you expanded the scope of the sentence to >> include built-in beans, producer methods, producer fields, and custom beans. >> I would suggest providing list of these changes, so we can review each one. >> >> > Java EE component was replaced by component (yes, I'm not sure it is >> > very meaningful) >> >> I also think this is problematic. A Java EE component is a specific thing. >> I would suggest providing list of these changes, so we can review each one. >> >> > >> > In the EE part, I added changed all "session bean" occurrences by "EJB >> > session bean”. >> >> Ok, I don’t think this is a problem. >> >> > >> > The step I see are: >> > >> > 0) Validate that we're all ok with the principle of splitting >> > 1) validate that all EJB references are removed from core >> > 2) Correct bad terminology that I introduced >> > >> > And then we should continue the splitting by rewriting the contexts >> > chapter and EL references in Core. >> >> +1 >> >> > >> > Antoine >> > _______________________________________________ >> > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > 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.