Maven 还不值得用于 EAR 部署吗？

Question

我正在将几个 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 bug 的问题，例如 WAR 插件“packagingExcludes”指令仅排除直接依赖项，而不排除任何传递性依赖项！不太有信心。我发现了这个特定问题的 JIRA 问题，但它仍然处于开放状态。

然后我发现我的命令行 Maven 2.2.1 的行为与我的 m2eclipse 嵌入式 Maven (Embedder v. 3.0) 不同。我们的开发人员肯定希望从 Eclipse 驱动 Maven，因此依赖最新的命令行版本不是一个选择。

所以，我的问题是：现在以及在可预见的未来，如果我们在 Eclipse 中进行所有开发并且主要在瘦小的 EAR 项目上工作，是否值得迁移到 Maven？ Maven 的未来是否有任何东西可以使其以更健壮和集成的方式处理 EAR？

Answer 1

所以，我的问题是：现在，以及未来
可预见的未来，是否值得
如果我们做了所有的事情就迁移到 Maven
在 Eclipse 中进行开发并工作
主要是在瘦小的 EAR 项目上？是
Maven 的未来有什么
会使其以更多的方式处理 EAR
稳健且集成的方式？

简短的故事：不，在 M2Eclipse 仍然损坏的情况下不会。

长话短说：

目前，我建议不要这样做，至少在 Eclipse 中是这样。在撰写本文时，M2Eclipse 插件一直存在一个非常令人讨厌的错误，即它生成自己版本的 application.xml 描述符文件，而不是使用 Maven 本来创建的版本。

不幸的是，这个自定义创建的 application.xml 是完全错误的：它忽略了 FinalNames，有一个明显硬编码的“lib/”前缀，并出于某种原因为 EJB JAR 分配了扩展名“.ejb”。更糟糕的是，您无法删除它以替换为 Maven 的版本，因为它不断被 M2Eclipse 重新生成。

如果 application.xml 尚未就位，Maven 只会生成它。由于 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 的准备。

Answer 2

不幸的是，这个自定义创建的 application.xml 是完全错误的：它忽略了 FinalNames，具有明显硬编码的“lib/”前缀，并出于某种原因为 EJB JAR 分配了扩展名“.ejb”。更糟糕的是，您无法删除它以替换为 Maven 的版本，因为它不断被 M2Eclipse 重新生成。

你真的确定这是 m2eclipse 做的吗？我正在使用 JBoss Tools 3.1，其中包括 m2eclipse 集成，并准确地解决您所说的问题。但是，我不认为 m2eclipse 根本不关心源 application.xml 的理由。

我怀疑 JBoss Tools 将信息注入到 application.xml 中。请证明我错了，我将永远停止使用 m2eclipse 因为它改变了 /target 下以外的任何内容。

//GG

Answer 3

我很震惊（是不是太强了？:)）发现 Maven 对此支持不是很好（...）

确实，Maven 不支持 skinny WARs （另请参阅 解决 Skinny Wars 问题 wiki 页面）非常好，因为这从一开始就没有计划，并且 Maven 假设胖 WAR。因此，构建瘦 WAR 和瘦 EAR 的方法实际上更多的是构建在现有插件之上的解决方法。是的，这很容易出错。

(...) 然后我发现我的命令行 Maven 2.2.1 的操作方式与我的 m2eclipse 嵌入式 Maven (Embedder v. 3.0) 不同。

请注意，您可以将 m2eclipse 配置为使用外部 Maven，而不是嵌入式 Maven。这实际上就是我所做的，我想要与 CI 引擎使用的版本完全相同的版本。

所以，我的问题是：现在以及在可预见的未来，如果我们在 Eclipse 中进行所有开发并且主要在瘦小的 EAR 项目上工作，是否值得迁移到 Maven？

我的建议很简单：如果 Maven 不支持您想要构建软件的方式（合法与否，这不是问题），就不要使用它。