Alexey,
Thank for the answer.
Just curious: in the end, do you really use the CDI Facet/Facet Version somewhere or not ?
In my case, the JAX-RS builder can be invoked because the project has the JAX-RS Nature, which can be installed via "Project>Configure>Add JAX-RS Nature" or when adding the JAX-RS Facet (which in turn will add the JAX-RS Nature). Until now, I did not need to check the version, but I even wonder if it makes sense to do so. It seems like I should just look for specific JAX-RS 1.1 and 2.0 classes in the project classpath to determine which implementation of the validator should be called.
Thanks.
On 03/13/2014 04:06 AM, Max Rydahl Andersen wrote:
On 13 Mar 2014, at 7:59, Xavier Coulon wrote:
Alexey,
Thanks for the feedback on CDI. What about the CDI Facet in the project settings ? Do you programmatically switch the value (1.0 vs 1.1) if jars changed in the classpath ?
That would be bad. it should either stick to what the facet state or add a warning/error saying there is a mismatch.
No we don't change the version of the facet if the classpath was changed. So if you install CDI Facet 1.0 and then update CDI jars to 1.1 then CDI Tools will treat the project as a CDI 1.1 project in spite of the 1.0 facet.
/max
I think m2e-wtp has some connectors for that, but some user may also just set a Target Server (AS6, AS7 or Wildfly, etc.).
I guess I'll also have different validation rules that will be activated depending on the version of the spec the user selected.
Best regards,
/Xavier
On 12 Mar 2014, at 18:24, Alexey Kazakov <akazakov@exadel.com> wrote:
On 03/12/2014 08:32 AM, Max Rydahl Andersen wrote:
Depends on how big differences there are. But in general, same plugin
supports multiple versions. Look at JDT, WTP, Hibernate, Seam, Ant,
Maven, etc. /max
And CDI too.
We keep all needed code in the same plugins.
We switch to desired implementation depending on user's classpath. So
users don't have to change any project settings/preferences/facets to
switch from CDI 1.0 to CDI 1.1. Changing CDI JARs is enough.
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen