4

我正在将几个 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？

4

3 回答 3

3

所以，我的问题是：现在以及在可预见的未来，如果我们在 Eclipse 中进行所有开发，并且主要从事瘦 EAR 项目，是否值得迁移到 Maven？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 进行繁重的摆弄。

于 2010-04-22T23:56:35.273 回答
1

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

你真的确定是 m2eclipse 这样做吗？我正在使用包含 m2eclipse 集成的 JBoss Tools 3.1 并得到你所说的问题。但是，我认为 m2eclipse 根本不关心源 application.xml 的基本原理。

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

//GG

于 2010-06-03T10:00:07.377 回答
0

我吓坏了（是不是太强了？:)）发现 Maven 不能很好地支持这一点（...）

事实上，Maven 并不很好地支持瘦 WAR（另请参阅解决瘦战争问题wiki 页面），因为这只是从一开始就没有计划好，而且 Maven 假设胖 WAR。因此，构建瘦 WAR 和瘦 EAR 的方式确实更多是构建在现有插件之上的变通方法。而且，是的，这很容易出错。

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

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

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

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

于 2010-02-10T15:15:41.260 回答