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