【问题标题】:Maven Multi Module benefits over simple dependencyMaven 多模块优于简单依赖
【发布时间】:2013-03-11 15:25:17
【问题描述】:

我在 maven 项目方面有几年的经验,即使是多模块项目(这让我讨厌 maven 的多模块功能(所以免责声明现在已经完成)),即使我真的很喜欢 maven,有些事情我无法得到明确的答案:

多模块 maven 项目的典型用例是什么?与简单的依赖和父 pom 相比,这样的结构有什么附加价值?

我见过很多多模块项目的配置,但所有这些都可以通过创建一个简单的依赖库结构来解决依赖项和配置),我还没有找到任何可以清楚地看到多模块结构的附加值的用例。

我一直发现这种结构会带来过度的复杂性而没有真正的好处:我在哪里遗漏了什么? (说实话,我可以得到一些ear 可以从这种结构中受益,但除了那个特定的用例之外,还有其他真正的用途和好处吗?)

【问题讨论】:

    标签: maven dependency-management maven-module


    【解决方案1】:

    我发现 maven 模块非常有用,原因如下:

    • 架构分层和边界

    例如,我创建了一个 maven 模块 application-contract,其中包含我的表示层看到的接口。所以我有 UI->Presenter-> application-contract 域。这样,我知道我的表示/UI 层将无法访问我的域/应用程序层中的类。如果我在 UI 中编码时域类不在类路径中,我将无法使用它们。我喜欢这种方式(利用类路径限制)。也许 Java 9 模块也可以解决这个问题,但是(不幸的是)我使用 Java 8。

    • 每次在一个模块中运行测试

    当我将代码更改为作为模块的层时(如前所述),我只能运行它的测试,而无需从我没有更改的代码中重新运行测试。这给了我速度。我的表示层测试需要大约 3 秒(300 次测试)。每次我将代码更改为 Presenter 或应用程序层以下的任何内容时,我都不希望我的数据库 H2 集成测试运行。或运行我的图像处理测试。因为这些做 IO 并且它们很慢。

    • 建筑

    几乎是一样的。当我将代码更改为 UI 时,我只需要构建和部署 UI 的东西(我的 UI 是用 Java 编写的)。

    【讨论】:

      【解决方案2】:

      多模块可以帮助您重用您的代码。 这是您在工作中感受到的最大好处之一。

      想象一下,如果您有 3 个带有安全层的 Web 项目,您将不得不复制粘贴您的代码 3 次并尝试将其与每个项目连接。

      但是,如果您创建一个具有特定工作的项目的安全模块会怎样。 将它注入到您的应用程序中即可轻松使用它,然后就可以使用了。

      正如@ben75 的回答中提到的,一个 Maven 构建命令和构建所有使用过的 jar 的正确顺序。你不会再想哪个取决于另一个。

      【讨论】:

      • 这是一个古老的讨论。但是,我对这些方面有一些疑问。我有一个旧项目 spring-boot,它是多模块 maven 项目。随着时间的推移,模​​块的数量显着增加。所有子模块都是 crons。现在随着时间的推移它会增长得更多,我们已经有大约 90 个模块并且很难管理,有时 intellij 不会全部加载或在一个 git repo 中我们删除了一个模块,在更改 repo 后有时它们会弄乱代码库。在这种情况下我应该采取什么方法?假设我的 crons 数量会增长更多。
      【解决方案3】:

      多模块的主要好处是

      • 一个 maven 命令一次构建所有模块。
      • 最重要的是:maven 会为您处理构建顺序。
      • 配置您的 CI 服务器也非常简单:一个 jenkins 作业即可构建所有内容。

      我已经参与过一个包含大约 30 个子模块的项目。有时,您需要更改模块以外的内容,并且运行一个命令并确保需要编译的所有内容都以正确的顺序编译是必须的。

      编辑

      为什么是 30 个子模块?

      具有大量功能、大量开发人员、基于模块的功能分离的庞大框架。这是一个现实生活中的用例,将代码分离到模块中非常有意义。

      【讨论】:

      • 构建顺序对我来说似乎是一个有效的论据,但您能否描述一下为什么需要 30 个(!)子模块?
      • 我曾在一个项目中有 12-15 个团队工作的情况。我们有一个包含大约 30 个模块的主要项目。它允许每个团队拥有其领域的所有权(2-4 个模块),并在团队之间提供明确的职责分离。这并不完美,但也没有 50 名开发人员一直在同一个包中混在一起那么糟糕(我在其他时候也经历过)
      • 仍然不清楚,为什么每个团队都不在自己的 jar 上工作,然后可以加入一个以 jar 作为依赖项的单模块项目?
      【解决方案4】:

      这是一个真实的案例。

      我有一个多模块项目(你的咆哮......我没有看到它有任何复杂性。)最终结果是一个 webapp,但我有不同的模块用于 api、impl 和 webapp。

      创建项目 12 个月后,我发现我必须使用从 jar 运行的独立进程与 Amazon S3 集成。我添加了一个依赖于 api/impl 的新模块,并为新模块中的集成编写代码。我使用程序集插件(或类似的东西)来创建一个可运行的 jar,现在我有一个可以部署在 tomcat 中的战争和一个可以部署在另一台服务器上的进程。我的 S3 集成过程中没有 Web 类,我的 Web 应用程序中没有 Amazon 依赖项,但我可以共享 api 和 impl 中的所有内容。

      3 个月后,我们决定创建一个 REST webapp。我们希望将其作为一个单独的应用程序来完成,而不仅仅是现有 web 应用程序中的新 URL 映射。简单的。又一个模块,另一个 webapp 是 maven 构建的结果,没有特别的修改。业务逻辑在 webapp 和 rest-webapp 之间很容易共享,我可以根据需要部署它们。

      【讨论】:

      • 这对我来说听起来是迄今为止最好的用例描述,而且您对另一个答案的评论证实了我的想法/感觉:多模块为多包装或大型项目提供价值。
      • 我实际上是在计划使用这个答案来演示在哪些情况下应该使用多模块。
      • 我知道这是旧的,但我想知道在 webapp 中包含 api / impl 有什么好处?我想这对我来说只是进一步提出了最初的问题 - 我看到也许 impl 应该使用 API 模块化,但是为什么像 webapp 和 API 的其他消费者这样的东西呢?
      • @BrandonV 所以你在想,与其让 webapp 成为整体构建中的一个模块,不如让它成为一个自己的项目,依赖于包含 api/impl 模块的项目?我认为这是一种完全有效的方法。就我而言,我没有看到或经历过任何痛苦,因为它是一个包含多个模块的项目。由于这一切都密切相关,我不想花时间将它们全部分离到一个单独的项目中,并发现在我自己的项目中制作模块更容易。
      • 要继续我上面的评论,我想这取决于我是否需要单独发布工件,或者将它们一起发布是否有意义。就我而言,因为我总是将它们全部部署在一起。在您的情况下,一起部署 api/impl 并在不同的时间/位置部署 webapp/api-webapp 和 integration-library 可能更有意义。
      【解决方案5】:

      我认为您在大多数使用多模块的项目中是正确的,实际上不需要它们。

      在我工作的地方,我们使用多模块项目(我认为这是有充分理由的)。我们有一些类似于面向服务的架构,所以每个应用程序

      • 客户端模块
      • 接口模块(在客户端和实现之间具有共享对象)
      • 一个实现模块
      • 战争模块

      我同意将实现和战争模块放在同一个实际模块中是可以的,但是(可以说)这样做的好处是解决问题的类之间非常明确的划分以及应用程序如何与外部通信世界。

      在之前仅涉及 Web 应用程序的项目中,我尝试将所有内容放在同一个模块中,因为考虑到我正在使用的模块,它使测试更容易。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-08-21
        • 2014-11-18
        • 2014-09-09
        • 2014-04-15
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多