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