Maven Multi Module优于简单依赖

时间:2013-03-21 22:01:30

标签: maven dependency-management

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

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

我已经看到了很多多模块项目的配置,但是所有这些项目都可以通过创建一个简单的依赖库结构来实现,这些结构依赖于他们自己的生命作为可交付成果(即使是父母pom,作为单独的可交付成果:factorising)依赖和配置)我没有找到任何用例,我可以清楚地看到多模块结构的附加值。

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

5 个答案:

答案 0 :(得分:23)

这是一个真实的生活案例。

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

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

之后3个月我们决定创建一个REST webapp。我们希望将其作为单独的应用程序,而不仅仅是现有Web应用程序中的新URL映射。简单。另外一个模块,另一个webapp作为maven构建的结果创建,没有特别的修补。 webapp和rest-webapp之间可以轻松共享业务逻辑,我可以根据需要进行部署。

答案 1 :(得分:12)

多模块的主要好处是

  • 一个maven命令一次构建所有模块。
  • 并且最重要的是:maven为您处理构建订单。
  • 配置CI服务器也非常简单:一个jenkins工作就可以构建所有内容。

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

修改

为什么有30个子模块?

巨大的框架,很多功能,很多开发人员,模块基础上的功能分离。这是一个真实的用例,将代码分离到模块中真的很有意义。

答案 2 :(得分:1)

我认为你是正确的,因为大多数项目使用多个模块,实际上并不需要它们。

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

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

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

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

答案 3 :(得分:0)

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

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

但是,如果您创建一个具有特定任务的项目,则将创建一个安全模块。 通过将其注入到您的应用程序中,然后使其繁荣起来,将很容易使用它。

也如@ ben75的回答中所述,一个maven build命令和正确的顺序来构建所有用过的jar。您将不再考虑哪个依赖另一个。

答案 4 :(得分:0)

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

  • 架构分层和边界

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

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

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

  • 建筑

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