[jbosstools-dev] Problem with project m2e vs validation during import

Fri Oct 11 14:01:45 EDT 2013

BTW we also have a special validation that checks the order of the 
builders and create a warning with a quickfix if there is a problem.
For example in CDI: 
https://github.com/jbosstools/jbosstools-javaee/blob/master/cdi/plugins/org.jboss.tools.cdi.core/src/org/jboss/tools/cdi/internal/core/validation/CDICoreValidator.java#L280
I think it's better to use such validation for your validator anyway. 
You can reuse it ( KBValidator.validateBuilderOrder()).
Let see what can happen if m2e enables CDI and JAX-RS when the project 
is importing as an existing maven project.
1. m2e enables CDI.
2. CDI tools add CDI builder and WST validation builder.
3. m2e, I guess, enables JAX-RS

So if JAX-RS tools just add its builder to the .project when CDI has 
been enabled then you will get a problem. You wil get something like 
this in the .project:

java builder
cdi builder
wst validation builder
jax-rs builder

So validation will be invoked before you JAX-RS builder.
It's not a problem for CDI validation since CDI tools take care of 
builder order when enabling CDI support.

If m2e is the last one in .project then I don't see problems here. If 
m2e builder changes any resources in the project then eclipse will run 
all the builders again.

On 10/11/2013 08:32 AM, Xavier Coulon wrote:
> Rob,
>
> That's what Fred showed me, too. But in my case, it's an import of an 
> existing project, thus the builders (JAX-RS, m2e and Validation, 
> amongst others) are already configured.
>
> Thanks for your help !
>
> Best regards,
> /Xavier
>
>
>
> On Oct 11, 2013, at 3:00 PM, Rob Cernich wrote:
>
>>> Xavier,
>>>
>>> Worth checking out if your two different flows might be caused by your
>>> validator/builder being added in different sequence. Causing you to miss
>>> java changes ?
>>
>> Max, I think the m2e builder always wants to be last: 
>> https://github.com/eclipse/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/ProjectConfigurationManager.java#L563
>>
>>>
>>> /max (sent from my phone)
>>>
>>>
>>>> On 10/10/2013, at 20.06, Alexey Kazakov <akazakov at exadel.com 
>>>> <mailto:akazakov at exadel.com>> wrote:
>>>>
>>>> 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 at lists.jboss.org 
>>>>>>>> <mailto:jbosstools-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>>> _______________________________________________
>>>>>>> jbosstools-dev mailing list
>>>>>>> jbosstools-dev at lists.jboss.org 
>>>>>>> <mailto:jbosstools-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20131011/6fae279f/attachment-0001.html 