Disclaimer: I'm a former maintainer of the org.codehaus.mojo
plugin, and author of the net.ltgt.gwt.maven
one.
The plugins have very different approaches to using GWT with Maven; I'll try to summarize the most important ones here.
First, the org.codehaus.mojo
is tied to a specific version of GWT; this means a new version of the plugin has to be released whenever a new version of GWT is released to account for differences. On the other hand, it exposes all GWT options/flags right as configuration properties, with Maven documentation (mvn gwt:help
) et al. When a bug is fixed in the plugin, this also means you have to update your GWT version to match the one used by the next plugin release; while you really should always use the latest GWT version, it might not be possible to update quickly due to other dependencies being incompatible with the new version, etc. so you may be in "version conflict hell".
The net.ltgt.gwt.maven
plugin aims at being compatible with the 2 latest versions of GWT, but is likely compatible with many more (it's just not tested / guaranteed); this means that you can update the plugin independently of GWT.
The org.codehaus.mojo
plugin brings the gwt-dev
and gwt-user
(and gwt-servlet
!) dependencies, which can cause conflicts with those from the project's dependencies if not strictly identical; also, due to how Maven works, you cannot exclude them from the plugin's dependencies if you use your own forked version of GWT under a different groupId
(you'd have to either use the com.google.gwt
groupId
, or fork the plugin to change its dependenceis).
The net.ltgt.gwt.maven
plugin comes with custom packaging
s for gwt-lib
and gwt-app
. It's quite opinionated on how GWT apps should be done with Maven: separating client and server (and shared) code into separate Maven modules (this is actually following The Maven Way™: if you need separate classpaths, then you need to use different Maven modules, each with their dependencies). You're of course not forced to use those packagings, they just cut quite a bit of configuration in the POMs by setting appropriate defaults and conventions.
Finally, because of that above-stated opinionated view on "project layout", the net.ltgt.gwt.maven
plugin is designed to support multi-module (aka reactor) builds, contrary to the org.codehaus.mojo
plugin where, for instance, gwt:run
has to be run on a project where both client and server code "live"; leading to awful hacks in multi-module builds like having to mvn install
all dependency modules (because gwt:run
cannot be invoked on the aggregator module) and using the build-helper-maven-plugin
to bring in client sources from the other modules for seamless development experience.
You can see the differences between the plugins in this commit on the gwt-maven-archetypes (disclaimer: I'm the author) which switched from the org.codehaus.mojo
to the net.ltgt.gwt.maven
plugin.