thank you very much, but I only understand parts of your posts, because maven is still new to me...
Actually, nothing. Nothing on the Maven side though.
Yes, I can validate this by doing mvn gwt:devmode and the app works, nevertheless what eclipse thinks is wrong...
The problem is with M2Eclipse, but I don't know it enough to know how you're supposed to work with it and give you any guidance here.
Well, I was used to do everything in eclipse: create gwt project, compile, run, debug, ... I just migrated one general library (pure java and gwt code) and two apps (which I recreated with webAppCreator -templates maven) to maven.
When I make changes to the library, I execute mvn clean compile package install. I feel that some of these goals should be triggered by others, but I call them all to make sure to end up in a defined state.
When I make changes to one of the apps, I execute mvn clean compile package gwt:devmode.
I know that all these goals must be redundant and triggered by each other somehow, but during the migration of my projects I have seen many problems that disappeared when repeating the different maven goals...
The problem is that "mvn war:war" is somehow invoked (do you invoke it yourself manually, from within Eclipse? possibly as "mvn package") and it resolves its dependencies from the workspace (by default at least), similar to a reactor build.
To reproduce the problem I don't need to call anything: I simply open the pom.xml in eclipse, remove the "provided" scope, and save the pom.xml file. Then, immediately, the error marker appears.
BTW: I don't know "reactor builds", so I cannot follow your additional words:
But when resolving the library, it won't build/package it! and Maven's default behavior when trying to resolve unpackaged dependencies from a reactor build, is to take target/classes if the dependency has <packaging>jar</packaging>This can happen in regular reactor builds when you e.g. run "mvn test": it'll run "mvn test" on the first submodule, then "mvn test" on the second submodule, and if the second submodule depends on the first one, then its target/classes is used (because "test" comes before "package" in the lifecycle). This is a design flaw in Maven (if you ask me), and one of the reasons I generally recommend using other builds tools (e.g. Gradle) instead.If you disable resolution of dependencies from the workspace in Eclipse, then the "mvn war:war" will resolve the library from the local repository instead (which means you'd have to "mvn install" the library to have the app see the changes).
The only thing I understand in this paragraph is that I have to "mvn install" the library, what I am actually doing, so that the apps can see it.
Since my app works when doing everything on the command line, the only thing I want is that the error markers disappear (assuming that they are false positives)...
My (personal) recommendation is to work with reactor (multi-module) builds, to only ever execute Maven commands on the root module, and to only ever use the "package" and "verify" lifecycle phases (and possibly "install" and/or "deploy" if you really need them).
I would like to follow this recommendation, but what exactly do I have to do?
This is one reason I built the net.ltgt.gwt.maven:gwt-maven-
plugin, because the old org.codehaus.mojo:gwt-maven- plugin could work that way.
This is one big questionmark for me! I am evaluating the different GWT maven plugins for a while, and I learned that yours is the one that is recommended. Then, I found that webAppCreator -templates maven creates a project template that I can work with. And I noticed net.ltgt.gwt.maven in the pom.xml. Therefore, I thought that I am using your plugin. But the error message discussed here is a "MojoExecutionException". The word "Mojo" seems to refer to the other plugin. That's confusing to me. Can you resolve this?
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.