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

Question

显然，有两个Maven插件的GWT：

这一个：

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

这一个：

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

有什么区别？

Answer 1

声明：我是org.codehaus.mojo插件的前维护者，也是net.ltgt.gwt.maven之一的作者。

这些插件与使用Maven的GWT有很不同的方法;我会尽力在这里总结最重要的。

首先，org.codehaus.mojo与特定版本的GWT绑定;这意味着只要发布新版本的GWT来解决差异，就必须发布新版本的插件。另一方面，它使用Maven文档（mvn gwt:help）等将所有GWT选项/标记公开为配置属性。当插件中的bug被修复时，这也意味着你必须更新你的GWT版本以匹配下一个插件版本使用的版本;虽然你应该始终使用最新的GWT版本，但由于其他依赖项与新版本不兼容等原因，可能无法快速更新，因此您可能处于“版本冲突地狱”中。
net.ltgt.gwt.maven插件旨在与最新版本的GWT兼容，但很可能与更多兼容（它只是未经测试/保证）;这意味着你可以独立于GWT更新插件。
org.codehaus.mojo插件带来了gwt-dev和gwt-user（和gwt-servlet！）的依赖关系，如果不是严格相同的话，这可能会导致与项目依赖项的依赖项发生冲突;另外，由于Maven的工作原理，如果您在不同的groupId下使用您自己的GWT版本的GWT，则无法将它们从插件的依赖项中排除（您必须使用com.google.gwtgroupId，或者让插件改变它的依赖性） 。

net.ltgt.gwt.maven插件自定义packaging s代表gwt-lib和gwt-app。关于如何使用Maven完成GWT应用程序，我们非常自信：将客户端和服务器（以及共享）代码分离成单独的Maven模块（这实际上是遵循Maven Way™的：如果您需要单独的类路径，那么您需要使用不同的Maven模块，每个都有它们的依赖关系）。您当然不会被迫使用这些容器，他们只是通过设置适当的默认值和约定来削减POM中的相当多的配置。

最后，因为在“项目布局”即上述固执视图中，net.ltgt.gwt.maven插件被设计为支持多模块（又名反应器）构建，这违背了org.codehaus.mojo插件，其中，例如，gwt:run必须是运行一个客户端和服务器代码都“活着”的项目;导致在多模块构建中出现可怕的黑客攻击，如不得不mvn install所有依赖项模块（因为不能在聚合器模块上调用gwt:run）并使用build-helper-maven-plugin从其他模块引入客户端源以获得无缝的开发体验。

你可以看到插件之间的差异this commit在GWT-Maven的原型（免责声明：我是作者）从org.codehaus.mojo切换到net.ltgt.gwt.maven插件。