10:36 a.m.
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
10:49 a.m.
New subject: Problem with project m2e vs validation during import
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
11:15 a.m.
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) :)
...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
11:50 a.m.
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
1:06 p.m.
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
1:22 a.m.
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 (sent from my phone)
On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)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(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
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
2:36 a.m.
Alexey,
Thanks for the pointer. I'll double check that this morning.
Best regards,
/Xavier
On Oct 11, 2013, at 8:22 AM, Max Andersen 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 (sent from my phone)
> On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)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(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
>
> _______________________________________________
> 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
8 a.m.
New subject: Problem with project m2e vs validation during import
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/...
/max (sent from my phone)
> On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)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(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
>
> _______________________________________________
> 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
10:32 a.m.
New subject: Problem with project m2e vs validation during import
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/...
>
> /max (sent from my phone)
>
>
>> On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)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(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
>>
>> _______________________________________________
>> 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
1:01 p.m.
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/o...
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/...
>
>>
>> /max (sent from my phone)
>>
>>
>>> On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)exadel.com
>>> <mailto:akazakov@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(a)lists.jboss.org
>>>>>>> <mailto:jbosstools-dev@lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>> _______________________________________________
>>>>>> jbosstools-dev mailing list
>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>> <mailto:jbosstools-dev@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@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
1:19 p.m.
----- Original Message -----
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/o...
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.
This may be part of the problem. If you have m2e-wtp and you're using facets,
validation may get disabled for target/ (part of the problem I had: I was waiting for the
output file to update before validating). I'm not sure of all the facets, but the
utility module facet does add ignore target/ to the validator preferences for the project.
https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp/src/or...
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/...
>
> > > /max (sent from my phone)
> >
>
> > > > On 10/10/2013, at 20.06, Alexey Kazakov <
akazakov(a)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(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
> > > >
> > >
> >
>
> > > > _______________________________________________
> > >
> >
>
> > > > 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
> >
>
> > _______________________________________________
>
> > 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
2:13 p.m.
On 10/11/2013 11:19 AM, Rob Cernich wrote:
This may be part of the problem. If you have m2e-wtp and you're using
facets, validation may get disabled for target/ (part of the problem I
had: I was waiting for the output file to update before validating).
I'm not sure of all the facets, but the utility module facet does add
ignore target/ to the validator preferences for the project.
https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp/src/or...
It's not a problem for JBT common validation which JAX-RS is based on.
This works only for wst validators v2. But we use wst validation v1
since v2 doesn't give you much control over the validation process. V2
is good for simple validation but if you need to do some sophisticated
validation then V2 is useless. Even V1 is not so useful but at least you
can control much more there. We probably should have used our own
implementation based on our own validation builder but anyway we managed
to adopt V1 for our pretty complex validators.
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/...
/max (sent from my phone)
On 10/10/2013, at 20.06, Alexey Kazakov
<akazakov(a)exadel.com <mailto:akazakov@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(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.orghttps://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
8:38 a.m.
> 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.
This may be part of the problem. If you have m2e-wtp and you're using facets,
validation may get disabled for target/ (part of the problem I had: I was waiting for the
output file to update before validating). I'm not sure of all the facets, but the
utility module facet does add ignore target/ to the validator preferences for the
project.
https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp/src/or...
why would you ever want to have target/ validated ? its the "compiled" form, not
something that would get or should have validation errors/markers set..
/max
> 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/...
> >
>
> > > > /max (sent from my phone)
> > >
> >
>
> > > > > On 10/10/2013, at 20.06, Alexey Kazakov < akazakov(a)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(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
> > > > >
> > > >
> > >
> >
>
> > > > > _______________________________________________
> > > >
> > >
> >
>
> > > > > 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
> >
>
> > _______________________________________________
>
> > 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
9:09 a.m.
>> 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.
>
>This may be part of the problem. If you have m2e-wtp and you're using
>facets, validation may get disabled for target/ (part of the problem I had:
>I was waiting for the output file to update before validating). I'm not
>sure of all the facets, but the utility module facet does add ignore
>target/ to the validator preferences for the project.
>
>https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp/src/org/eclipse/m2e/wtp/UtilityProjectConfigurator.java#L73
why would you ever want to have target/ validated ? its the "compiled" form,
not something that would get or should have validation errors/markers set..
The file is composed by various "scanners" meaning the file is compiled from
various sources. Because of that, configuration must occur after the output of all these
scanners has been merged.
/max
>> 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/...
>> >
>>
>
>> > > > /max (sent from my phone)
>> > >
>> >
>>
>
>> > > > > On 10/10/2013, at 20.06, Alexey Kazakov <
akazakov(a)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(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
>> > > > >
>> > > >
>> > >
>> >
>>
>
>> > > > > _______________________________________________
>> > > >
>> > >
>> >
>>
>
>> > > > > 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
>> >
>>
>
>> > _______________________________________________
>>
>> > 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
9:46 a.m.
On Mon, Oct 14, 2013 at 10:09:38AM -0400, Rob Cernich wrote:
> >> 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.
> >
> >This may be part of the problem. If you have m2e-wtp and you're using
> >facets, validation may get disabled for target/ (part of the problem I had:
> >I was waiting for the output file to update before validating). I'm not
> >sure of all the facets, but the utility module facet does add ignore
> >target/ to the validator preferences for the project.
> >
>
>https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp/src/org/eclipse/m2e/wtp/UtilityProjectConfigurator.java#L73
>
> why would you ever want to have target/ validated ? its the "compiled"
form,
> not something that would get or should have validation errors/markers set..
The file is composed by various "scanners" meaning the file is compiled from
various sources. Because of that, configuration must occur after the output of all these
scanners has been merged.
hmm...that sounds like a leaky abstraction problem then ;/
...sounds like there should be a generated-source folder instead then as a
"stage" before it gets into target folder which (afaik) is *not* validated by
anything else ?
btw. I assume you mean *validation* and not configuration or is the configuration *also*
dependent on this ?
/max
>
> /max
>
> >> 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/...
> >> >
> >>
> >
> >> > > > /max (sent from my phone)
> >> > >
> >> >
> >>
> >
> >> > > > > On 10/10/2013, at 20.06, Alexey Kazakov <
akazakov(a)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(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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >> > > > > _______________________________________________
> >> > > >
> >> > >
> >> >
> >>
> >
> >> > > > > 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
> >> >
> >>
> >
> >> > _______________________________________________
> >>
> >> > 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
>
>
8:24 a.m.
On Fri, Oct 11, 2013 at 09:00:04AM -0400, 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/...
yes, but if another one adds builder after this code is run = strange things could happen
;)
/max
>
> /max (sent from my phone)
>
>
> > On 10/10/2013, at 20.06, Alexey Kazakov <akazakov(a)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(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
> >
> > _______________________________________________
> > 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
>
1:19 a.m.
I think you misunderstood me :)
I said that was a bad direction to go.
The general tools shouldn't need to be dependent on maven/m2e.
Work great with m2e is good.
Being 100% dependent on it is bad.
/max (sent from my phone)
On 10/10/2013, at 18.50, Rob Cernich <rcernich(a)redhat.com> 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
>
>
4092
days inactive
4096
days old
jbosstools-dev@lists.jboss.org
16 comments
5 participants
participants (5)
-
Alexey Kazakov -
Max Andersen -
Max Rydahl Andersen
-
Rob Cernich -
Xavier Coulon