I didn't notice any problems with CDI validation for m2e projects.
But when we enable CDI support on the project (there is the only method
for that which is used by m2e, preference pages, new project wizard,
install facet delegates, etc)
we make sure we have builders in .project in a proper order.
So we don't just add cdi and validation builders. We re-order the list
of builders in .project. See
WebModelPlugin.addNatureToProjectWithValidationSupport();
In our case four builders are critical: Java, KB, CDI, WST validation.
And the order of these builders is critical for us.
Every time m2e changes something in the project, the whole stack of
builders is invoked and even if it does change the project step-by-step
the final changing/building will fix false validation problems caused by
previous changes.
On 10/10/2013 09:50 AM, Rob Cernich wrote:
> There is something badly wrong if we need to start making that
the habit (if
> your project is m2e then disable the validation and do it in a maven
> plugin/extension instead) :)
Yes. That is the plan moving forward, but it was easier to get validation into the
tooling than it was to get it into the mojo, so...
> ...but that said - I know we've seen more than a few issues with m2e vs
> eclipse causing "havoc" on builds.
>
> /max
>
> On Thu, Oct 10, 2013 at 11:49:10AM -0400, Rob Cernich wrote:
>> Hey Xavier,
>>
>> I had a similar problem with the SwitchYard validator. Upon further
>> investigation, it appears m2e wants the Maven builder to be last in the
>> list. Based on that, I eventually gave up, disabled the SwitchYard
>> validator from the build and invoked it directly from the SwitchYard m2e
>> build participant. I suspect something similar will probably need to be
>> done in your case, assuming there is a JAX-RS participant for m2e.
>>
>> Hope that helps,
>> Rob
>>
>> ----- Original Message -----
>>
>>> hello,
>>> I'm banging my head against the wall trying to fix this issue: On a Full
>>> Publish LiveReload refreshes the browser before the application is fully
>>> restarted
>>> Here's the context: I have a kitchensink project in which there are are
>>> JAX-RS errors (a custom JAX-RS HTTP Method is missing some annotations)
>>> Now, here's the problem I have:
>>> - in some cases, the metamodel exists and is complete (i.e.: the m2e
>>> dependencies were properly set *before* the metamodel was built), and
>>> then,
>>> the validation occurs on the whole project, and I have the expect errors
>>> reported.
>>> - in other cases, the validation on the whole project is executed *before*
>>> m2e did set the dependencies on the project's classpath. At this stage,
>>> the
>>> metamodel exists but it is empty (the java classes have compilation errors
>>> because of missing libs, so no JAX-RS element was created). The metamodel
>>> is
>>> completed after m2e updated the project's classpath, but then a
validation
>>> job is triggered because of bunch of xml files (not related to the JAX-RS
>>> classes) were processed by m2e and copied into the /target/classes output
>>> folder. This means that the full validation was not executed.
>>> Basically, it looks as if some operations (m2e / JAX-RS / validation)
>>> don't
>>> always occur in the same order, which sometimes result in incomplete
>>> validation and missing markers as expected. (not to mention that I have no
>>> clue how to force the order of execution, which makes the debugging *not
>>> fun*...)
>>> Any idea how I could make sure the validation (based on
>>> org.jboss.tools.common.validation) could be always called on the project
>>> after m2e sets the dependencies in the classpath ?
>>> Thanks for your help ;-)
>>> Best regards,
>>> /Xavier
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev