Saturday, April 22, 2017

Re: GWT/Maven development cycle takes much too long

On Friday, April 21, 2017 at 7:38:37 PM UTC+2, Magnus wrote:

So, "mvn package" should Just Work™ (package the lib, then package the app using the lib's jar).

Yes, works!
"mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much configuration (configure warDir/launcherDir, possibly projects/modules)

Actually, it gives an error (see below):

Could not find goal 'devmode' in plugin org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals...

I believe I have to extend the minimal top-level pom.xml, but how?
And I'd like to leave the pom.xml in the sub folders as is, because they are working for their own... Is this possible?

As I said, the MojoHaus plugin doesn't work well in reactor builds, it simply hasn't been designed to support them.
The net.ltgt.gwt.maven:gwt-maven-plugin (where the devmode and codeserver goals can be found) has been specifically designed for that.
You can probably mix both plugins (i.e. keep the MojoHaus plugin in the submodules for the build, use the net.ltgt.gwt.maven plugin in the root module only for the devmode/codeserver goals) with a bit more configuration (explicit projects and modules, rather than automatic discovery in submodules).
This is also the point with the development cycle: When debugging, eclipse doesn't "see" the changed library source code, because it fetches the library source code from the jar file in its own target folder.

Actually the one from your local repository (~/.m2/repository/), not directly the one from the target/ folder.

This is an important point! If the app used the library jar from the repository and not from its own target directory, there would be no need to "mvn package" the app and this takes most of the time...
Wouldn't it be better for developing if the original library code was used instead? Could it be that this is the core of the problem?

And the problem is that Eclipse errors when importing your app project when using the default configuration for resolving dependencies from the workspace; which is why you turned that setting off.
If you figure out how to get this working, then it should (hopefully work) the same with or without a reactor.

I can enable it for the lib project without problems. But as soon as I enable it for the app project, the error reappears.
It's hard to figure it out when even the experts in this group have no idea. But I see that this is an essential point, so I have documented the error as detailed as possible again (see below). I hope there will be a solution...

It really doesn't look like this is specific to GWT; so if I were you I'd ask on the M2Eclipse mailing list (if any) and/or on StackOverflow. You (a priori) need to find Eclipse/M2Eclipse experts, not GWT experts that (possibly) happen to use Eclipse/M2Eclipse. It looks really strange to me that Eclipse attemps to package the project on import, and this is the crux of the problem (it is the maven-war-plugin that's failing).
It would probably help to know the exact version of Eclipse (and M2Eclipse, WTP, and m2e-wtp plugins) you're using, and any other plugin you have installed that could trigger that behavior (reproducing in an out-of-the-box Eclipse install would allow excluding bad plugin interactions).
Having a small (as small as possible, just a jar and war projects, no external dependencies besides javax.servlet) project available (e.g. on GitHub) would also help, so that others could try to reproduce the problem from the same sources.

(also, maven-war-plugin 2.2 is 5 years old already, maybe try using a more recent version? if you don't explicitly specify a version, try a newer Maven version; though the one Eclipse uses is likely the one it bundles, so it depends directly on the version of the M2Eclipse plugin being used)

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
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment