<div dir="ltr">BTW during the F2F meeting we discussed the idea of having a &quot;global&quot; beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea is to be able to include/exclude globally.<div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba <span dir="ltr">&lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a):<br>
<span class="">&gt; Interesting, couldn&#39;t excludes supports it? when processing extensions<br>
&gt; we have the beans.xml model so extensions could be filtered this way, no?<br>
<br>
</span>No. beans.xml excludes are local (i.e. per bean archive). Extensions are<br>
global - per application.<br>
<br>
&gt;<br>
&gt;<br>
&gt; Romain Manni-Bucau<br>
&gt; @rmannibucau &lt;<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>&gt; | Blog<br>
&gt; &lt;<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>&gt; | Github<br>
&gt; &lt;<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>&gt; | LinkedIn<br>
&gt; &lt;<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>&gt; | Tomitriber<br>
&gt; &lt;<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>&gt;<br>
<span class="">&gt;<br>
&gt; 2015-10-01 13:44 GMT-07:00 arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a><br>
</span>&gt; &lt;mailto:<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;&gt;:<br>
<span class="">&gt;<br>
&gt;     There&#39;s an existing issue for this:<br>
&gt;     <a href="https://issues.jboss.org/browse/CDI-157" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-157</a><br>
&gt;<br>
&gt;     The JSF EG is also really interested in this, for<br>
&gt;     <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361" rel="noreferrer" target="_blank">https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361</a> and<br>
&gt;     several other things.<br>
&gt;<br>
&gt;     Kind regards,<br>
&gt;     Arjan Tijms<br>
&gt;<br>
&gt;<br>
&gt;     On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti<br>
</span><div><div class="h5">&gt;     &lt;<a href="mailto:antonin@stefanutti.fr">antonin@stefanutti.fr</a> &lt;mailto:<a href="mailto:antonin@stefanutti.fr">antonin@stefanutti.fr</a>&gt;&gt; wrote:<br>
&gt;      &gt; Hi CDI mates,<br>
&gt;      &gt;<br>
&gt;      &gt; I’ve been developing a couple of CDI extensions over the last<br>
&gt;     couple of<br>
&gt;      &gt; years and been facing this recurrent situation:<br>
&gt;      &gt; - I develop the extension against the latest CDI release version<br>
&gt;     (1.2 for<br>
&gt;      &gt; the time being),<br>
&gt;      &gt; - As the extension gets used, comes the requests to run the<br>
&gt;     extension in<br>
&gt;      &gt; previous CDI versions,<br>
&gt;      &gt; - As any real-world extensions heavily rely on the CDI SPI, they<br>
&gt;     never<br>
&gt;      &gt; happen to be backward-compatible,<br>
&gt;      &gt; - And that’s understandable that the end-users won’t upgrade its<br>
&gt;     runtime<br>
&gt;      &gt; environment for just one extension.<br>
&gt;      &gt;<br>
&gt;      &gt; One option is to rewrite the extension against the oldest<br>
&gt;     required CDI<br>
&gt;      &gt; version (generally 1.0 as a lot of people still use that version<br>
&gt;     as part of<br>
&gt;      &gt; Java EE 6) by working around lacking functionalities from the CDI<br>
&gt;     SPI at the<br>
&gt;      &gt; cost of code readability or even removed features that are<br>
&gt;     impossible to<br>
&gt;      &gt; re-implement.<br>
&gt;      &gt;<br>
&gt;      &gt; To avoid that, it is obviously possible to create a separate<br>
&gt;     branch / module<br>
&gt;      &gt; dedicated to porting the extension to the oldest possible CDI<br>
&gt;     version, but<br>
&gt;      &gt; then comes the packaging / distribution problem:<br>
&gt;      &gt; -  You assign different versions to the branches, unfortunately<br>
&gt;     that does<br>
&gt;      &gt; not work for projects that include their own CDI extension into<br>
&gt;     the same<br>
&gt;      &gt; codeline (like Apache Camel, JBoss Infinispan, …) as it doesn’t<br>
&gt;     make sense<br>
&gt;      &gt; to impact the whole project versioning for one possible container<br>
&gt;     / runtime<br>
&gt;      &gt; among others possible,<br>
&gt;      &gt; - Or you create two artifacts / modules whose name (or<br>
&gt;     classifier) somehow<br>
&gt;      &gt; contains the CDI compatible version.<br>
&gt;      &gt;<br>
&gt;      &gt; That’s not very ideal either, and in any case, that’s the end<br>
&gt;     user burden to<br>
&gt;      &gt; make the decision which artifact to choose from a list that will<br>
&gt;     grow over<br>
&gt;      &gt; time with CDI 2.0 and future CDI versions.<br>
&gt;      &gt;<br>
&gt;      &gt; Which leads to my point... As there exists a way to add / veto<br>
&gt;     annotated<br>
&gt;      &gt; types and beans programmatically, one solution that will help<br>
&gt;     addressing the<br>
&gt;      &gt; above problems, both for the extension developers and users,<br>
&gt;     would be to<br>
&gt;      &gt; have the ability to add / veto extensions dynamically. That way,<br>
&gt;     multiple<br>
&gt;      &gt; version / part of the extension could be packaged into a single<br>
&gt;     artifact and<br>
&gt;      &gt; activated dynamically during the application initialisation phase<br>
&gt;     based on<br>
&gt;      &gt; some runtime criteria, in my use case the CDI environment<br>
&gt;     version. The point<br>
&gt;      &gt; here is not to discuss potential implementations, but we could<br>
&gt;     imagine<br>
&gt;      &gt; having an AfterExtensionDiscovery of BeforeTypeDiscovery<br>
&gt;     lifecycle event<br>
&gt;      &gt; from which adding or vetoing extensions would be possible, or some<br>
&gt;      &gt; mechanisms in the beans.xml file to include / exclude an extension...<br>
&gt;      &gt;<br>
&gt;      &gt; So before discussing implementation details, I’d like your<br>
&gt;     opinion on that<br>
&gt;      &gt; use case, whether it’s valid or other options exist.<br>
&gt;      &gt;<br>
&gt;      &gt; Thanks,<br>
&gt;      &gt; Antonin<br>
&gt;      &gt;<br>
&gt;      &gt; _______________________________________________<br>
&gt;      &gt; cdi-dev mailing list<br>
</div></div>&gt;      &gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
<span class="">&gt;      &gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;      &gt;<br>
&gt;      &gt; Note that for all code provided on this list, the provider<br>
&gt;     licenses the code<br>
&gt;      &gt; under the Apache License, Version 2<br>
&gt;      &gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;     ideas<br>
&gt;      &gt; provided on this list, the provider waives all patent and other<br>
&gt;     intellectual<br>
&gt;      &gt; property rights inherent in such information.<br>
&gt;<br>
&gt;     _______________________________________________<br>
&gt;     cdi-dev mailing list<br>
</span>&gt;     <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
<span class="im HOEnZb">&gt;     <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;<br>
&gt;     Note that for all code provided on this list, the provider licenses<br>
&gt;     the code under the Apache License, Version 2<br>
&gt;     (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;     ideas provided on this list, the provider waives all patent and<br>
&gt;     other intellectual property rights inherent in such information.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cdi-dev mailing list<br>
&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;<br>
&gt; 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" rel="noreferrer" 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>
&gt;<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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" rel="noreferrer" 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" rel="noreferrer" 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.</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div></div>
</div>