我正在将几个J2EE项目从Ant移植到Maven2。所有这些项目都包含1个EJB和1个Web模块，并使用推荐的“瘦”EAR打包方法。这意味着EJB和/或Web模块所依赖的JAR都只是放在EAR的根目录中。 EJB和Web模块在各自的清单中都有Class-Path条目来引用特定的JAR，而Web模块Class-Path也将引用EJB jar。
我吓坏了（太强了吗？:)）发现Maven不太支持这个。我阅读了关于处理瘦的WAR的官方页面，但这意味着我必须复制EAR pom中的WAR依赖项，更糟糕的是，还有传递依赖项。如果你必须在任何地方手动处理依赖，那么采用Maven似乎毫无意义！
然后我开始谷歌搜索并发现了各种变通方法 - 显然，我不是第一个（a）想要做一个瘦小的EAR和（b）不喜欢Maven建议的方法（它本身就是解决方法）。
我尝试了其中一些方法，但没有一个适合我。我还发现了一些看起来像Maven错误的问题，例如： WAR插件'packagingExcludes'指令只排除直接依赖，而不是任何传递依赖！不是很自信鼓舞人心。我找到了这个特定问题的JIRA问题，但它仍然是开放的。
然后我发现我的命令行Maven 2.2.1对我的m2eclipse嵌入式Maven（Embedder v.3.0）做了不同的事情。我们的开发人员肯定希望从Eclipse驱动Maven，因此依赖最新的命令行版本不是一种选择。
所以，我的问题是：现在，对于可预见的未来，如果我们在Eclipse中进行所有开发并且主要在瘦的EAR项目上工作，是否值得迁移到Maven？ Maven的未来有什么能够以更强大和集成的方式处理EAR吗？
答案 0 :(得分：3)
所以，我的问题是：现在，而且 可预见的未来，值得 如果我们全力以赴，就转移到Maven Eclipse中的开发和工作 主要是在瘦的EAR项目上？是 在Maven的未来有什么 会让它更多地处理EAR 强大而综合的方式？
短篇小说：不，不是在M2Eclipse被打破的情况下。
长篇故事：
目前，我建议反对它，至少在Eclipse中。在撰写本文时，M2Eclipse插件总是有一个非常讨厌的错误，它会生成自己的application.xml描述符文件版本，而不是使用Maven会创建的那个。
不幸的是，这个自定义创建的application.xml是完全错误的：它忽略了finalNames，有一个明显硬编码的“lib /”前缀，并且由于某种原因将EJB JAR分配给扩展名“.ejb”。更糟糕的是，你无法删除它以替换为Maven的版本，因为它不断被M2Eclipse重新生成。
Maven只会生成application.xml（如果它还没有到位）。因为WTP / M2Eclipse生成的application.xml不断重新生成，所以Maven application.xml没有机会。
但是这个问题有一个解决方法：你可以告诉Maven在打包期间忽略application.xml，以便它认为 application.xml不存在，在这种情况下它仍会生成它自己的版本。这样，错误生成的application.xml文件无关紧要。供将来参考：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<version>5</version>
<earSourceExcludes>**/application.xml</earSourceExcludes>
<generateApplicationXml>true</generateApplicationXml>
</configuration>
</plugin>
然而，一个主要问题是用于部署到Eclipse中的GlassFish的Ant脚本生成自己单独的EAR以进行部署，并使用M2Eclipse生成的application.xml来执行此操作。这意味着只要M2Eclipse插件仍然存在，它生成的EAR将始终是错误的。在codehaus JIRA上有关于此的错误报告，但现在无法访问它们。
其他应用程序服务器的YMMV，但要准备好重复使用application.xml。
答案 1 :(得分：1)
不幸的是，这个自定义创建的application.xml是完全错误的：它忽略了finalNames，有一个明显硬编码的“lib /”前缀，并且由于某种原因将EJB JAR分配给扩展名“.ejb”。更糟糕的是，你无法删除它以替换为Maven的版本，因为它不断被M2Eclipse重新生成。
你真的确定m2eclipse这样做吗？我正在使用JBoss Tools 3.1，其中包括m2eclipse集成，并准确地说明了你所说的问题。但是，我没有看到m2eclipse关于源application.xml的理由。
我怀疑JBoss Tools会将信息注入application.xml。请证明我错了，我会永远停止使用m2eclipse，它改变了任何不在/目标之下的东西。
// GG
答案 2 :(得分：0)
我吓坏了（太强了吗？:)）发现Maven不支持这个（...）
实际上，Maven不支持skinny WARs（另请参阅Solving the Skinny Wars problem wiki页面），因为这只是从一开始就没有计划，而且Maven假设有胖的WAR。因此，构建瘦的WAR和瘦EAR的方式确实是在现有插件之上构建的变通方法。而且，是的，这很容易出错。
（...）然后我发现我的命令行Maven 2.2.1对我的m2eclipse嵌入式Maven（Embedder v.3.0）做了不同的事情。
请注意，您可以将m2eclipse配置为使用外部Maven而不是嵌入式Maven。这实际上就是我所做的，我想要与CI引擎完全相同的版本。
所以，我的问题是：现在，对于可预见的未来，如果我们在Eclipse中进行所有开发并且主要在瘦的EAR项目上工作，是否值得迁移到Maven？
我的建议很简单：如果Maven不支持你想要构建软件的方式（合法与否，这不是问题），请不要使用它。