<div dir="ltr"><div class="gmail_extra">Pete/all</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for the clarification. It seems, otherwise he would not have pointed out the issue in the first place, Anatole is also not able even as a Co Spec Lead to take a driving seat on that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I am Co Spec Lead of JSR 363 - Unit of Measurement (which especially in the SE implementation optimized for SE/EE 8+ seems like there are synergies for a typesafe definition of config elements;-) ) so other than assisting one or the other Spec Lead found for this I do not see reason to take more than one Spec Lead responsibility at a time, otherwise, jut look at the misery of JSR 310 or 107;-D </div><div class="gmail_extra"><br></div><div class="gmail_extra">Are there any observers/experts here or in EE 8 that would feel like helping lead such a JSR?</div><div class="gmail_extra">Anatole and I also spoke to CloudBees (a company you sure know well) and there was general interest, but I recall they had slightly different views on some things, but as EG Member both they and maybe other players (e.g. Pivotal or someone from DeltaSpike both with an approach to config) would be qualified EG Members or Co Spec Leads for this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As you know it would be best if a true Individual who is self employed (e.g. Antonio?;-)) did this, otherwise an employee of a company, even more if they have something to do with Java could run into IP and patent troubles, I talk from the experience in EC and IP WG of JSR 358;-)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anybody willing and able to help?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll be at JavaZone next week, speaking with e.g. Arun or (EE EG Member) Jeff Genender, so if there is no sound interest in this list, we can certainly talk about it in Oslo, too.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Werner</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 4:50 PM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would just like to note that we definitely support the idea of a Config JSR. And we would provide strong EG representation, and help with RI/TCK. However we are unable to take a lead role in it right now, due to having many other things going on.<br>
<div class="HOEnZb"><div class="h5"><br>
On 5 Sep 2014, at 15:43, Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>> wrote:<br>
<br>
> You got a point, but so far both Oracle and Red Hat dismissed the idea of a separate Config JSR. Anatole was in touch with both of them and either their resources or interest seemed to lack.<br>
><br>
> It is quite a shamble, that e.g. JSR 107 already went down the path of a completely separate Config sub-system (<a href="https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration" target="_blank">https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration</a>) while pruning other much more importent (especially for true EE 8 value) features like Transaction Support in line with JTA, etc.<br>
><br>
> If CDI2 needed a config sub-system, too, we better avoid their mistake or (for EE 8 since it is considered for inclusion) look at ways this may work together in some unified way.<br>
> Whether it's a separate JSR or "Module" of CDI 2 I don't really care, but we must not fall into the same "Not invented Here" trap as Java SE did with all its redundant and bloated features like JavaFX having its own Date/Time same as java.util.Date (which aside from JSR 236 also is the only one relevant to EE, JDBC, etc.) or the extra package java.time.<br>
><br>
> JCache already went in the wrong direction here, as it is final there is probably not a lot to do, but do we really want to end up with<br>
> - JCache-config<br>
> - CDI-config<br>
> - MVC-config<br>
> ...<br>
><br>
> ??;-O<br>
><br>
> Werner<br>
><br>
> On Fri, Sep 5, 2014 at 4:24 PM, <<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a>> wrote:<br>
> Send cdi-dev mailing list submissions to<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
><br>
> You can reach the person managing the list at<br>
> <a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of cdi-dev digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event<br>
> observers (Martin Kouba (JIRA))<br>
> 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil)<br>
> 3. Re: With the end of Java Config... (John D. Ament)<br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Fri, 5 Sep 2014 10:24:37 -0400<br>
> From: "John D. Ament" <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>><br>
> Subject: Re: [cdi-dev] With the end of Java Config...<br>
> To: Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <<a href="mailto:CAOqetn8UrpdWEFV8LJJ57hJ%2Bz-iAFNjEEzyqsfPXFUQutuqT8A@mail.gmail.com">CAOqetn8UrpdWEFV8LJJ57hJ+z-iAFNjEEzyqsfPXFUQutuqT8A@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate<br>
> spec. While we can provide a way to wire up beans externally w/ an XML<br>
> DSL, I don't think we should get into the business of config properties,etc.<br>
><br>
><br>
> On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves <<br>
> <a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>> wrote:<br>
><br>
> > One wise man* once said "EJB was a hype specification, we added too many<br>
> > things to it, it became bloated. The next hype specifications are JAX-RS<br>
> > and CDI, careful with them"<br>
> ><br>
> > Either we get this idea of "parts" right, or CDI will endup being bloated.<br>
> ><br>
> > Antonio<br>
> ><br>
> ><br>
> > *David Blevin<br>
> ><br>
> ><br>
> > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <<br>
> > <a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
> ><br>
> >> Hi all,<br>
> >><br>
> >> You may have followed the rise and fall of the Java Config JSR (<br>
> >> <a href="http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html" target="_blank">http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html</a><br>
> >> ).<br>
> >> Anatole in CC was leading this initiative and I proposed him to join us<br>
> >> and explore if some part of his late-JSR could be done in CDI.<br>
> >><br>
> >> I?m mainly thinking of <a href="https://issues.jboss.org/browse/CDI-123" target="_blank">https://issues.jboss.org/browse/CDI-123</a> or<br>
> >> related solution. If we achieve to have a majority of specs to integrate<br>
> >> with CDI, our configuration solution would therefore become a configuration<br>
> >> system for all spec based on CDI 2.0.<br>
> >><br>
> >> Antoine<br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> cdi-dev mailing list<br>
> >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> >><br>
> >> Note that for all code provided on this list, the provider licenses the<br>
> >> code under the Apache License, Version 2 (<br>
> >> <a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> >> provided on this list, the provider waives all patent and other<br>
> >> intellectual property rights inherent in such information.<br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Antonio Goncalves<br>
> > Software architect, Java Champion and Pluralsight author<br>
> ><br>
> > Web site <<a href="http://www.antoniogoncalves.org" target="_blank">http://www.antoniogoncalves.org</a>> | Twitter<br>
> > <<a href="http://twitter.com/agoncal" target="_blank">http://twitter.com/agoncal</a>> | LinkedIn<br>
> > <<a href="http://www.linkedin.com/in/agoncal" target="_blank">http://www.linkedin.com/in/agoncal</a>> | Pluralsight<br>
> > <<a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">http://pluralsight.com/training/Authors/Details/antonio-goncalves</a>> | Paris<br>
> > JUG <<a href="http://www.parisjug.org" target="_blank">http://www.parisjug.org</a>> | Devoxx France <<a href="http://www.devoxx.fr" target="_blank">http://www.devoxx.fr</a>><br>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider licenses the<br>
> > code under the Apache License, Version 2 (<br>
> > <a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> > provided on this list, the provider waives all patent and other<br>
> > intellectual property rights inherent in such information.<br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/2ab10644/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/2ab10644/attachment.html</a><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
><br>
> End of cdi-dev Digest, Vol 46, Issue 17<br>
> ***************************************<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
</div></div></blockquote></div><br></div></div>