net.ltgt.gwt.maven和org.codehaus.mojo GWT Maven插件有什么区别？

Question

Apparently, there are two maven plugins for GWT:

This one:

<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.0-rc-6</version>

and this one:

<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.8.0-SNAPSHOT</version>

What are the differences ?

Answer 1

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.