我有一个关于 Maven 的多模块项目的一般性问题。何时何地去争取它?
4 回答
@Esko Luontola 的答案
将项目拆分为多个模块很有用,例如,如果需要单独部署模块,..
可能会被误解。如果您有将单独部署的模块,则恰恰相反。在这种情况下,您永远不应该创建多模块构建。这应该通过简单的独立 Maven 项目来完成。
多模块构建的想法是,如果您有像 ear 项目一样属于一起的模块,该项目通常由客户端、服务器、ejb、war 等几个其他模块组成。这通常通过多模块构建来处理,这意味着所有模块具有相同的版本号,但可以由其他模块单独访问和使用。
这个问题似乎更多地是关于软件的。Maven 只是其中一种方式。
什么是组件?这是软件中一个可怕的超载术语,因此我们将尝试尽可能清楚地说明我们的意思。当我们谈论组件时,我们指的是应用程序中相当大规模的代码结构,具有定义良好的 API,可能会被替换为另一个实现。基于组件的软件系统的区别在于代码库被分成离散的部分,这些部分通过与其他组件的定义良好、有限的交互来提供行为。基于组件的系统的对立面是一个单体系统,在负责不同任务的元素之间没有明确的边界或关注点分离。单片系统通常具有较差的封装性,
...
采用基于组件的设计通常被描述为鼓励重用和良好的架构属性,例如松散耦合。这是事实,但它还有另一个重要的好处:它是大型开发团队协作的最有效方式之一。
...
许多项目都可以使用单个版本控制存储库和简单的部署管道。然而,许多项目已经演变成无法维护的代码泥潭,因为没有人决定在成本低廉的情况下创建离散组件。小项目变成大项目的点是流动的,会偷偷摸摸地找你。
...
最后,值得注意的是康威定律,它指出“设计系统的组织. . . 受限于生产复制这些组织的通信结构的设计。”4 因此,例如,开发人员仅通过电子邮件进行通信的开源项目往往是非常模块化的,接口很少。由一个小型的、位于同一地点的团队开发的产品往往是紧密耦合的,而不是模块化的。小心你如何建立你的开发团队——它会影响你的应用程序的架构。
我发现这最后的陈述是如此清晰和准确,令人惊讶。我强烈推荐那本书!:-)
将项目拆分为多个模块很有用,例如,如果模块需要单独部署,或者在库的情况下,项目的某些使用者只需要类的子集,或者库的开发人员想要明确区分在什么是公共 API 和什么是私有实现之间。对于大型项目,它可能会使代码更容易保持有序,即使代码在技术上可能都在同一个模块中。
还有一些我会推荐使用多模块 maven 项目的用例:
您的模块共享相同的依赖项,在这种情况下,您将在主 pom 中指定所有依赖项,并且所有模块都可以享受它。(无需为每个模块指定相同的依赖项。)
如果您需要同时对多个项目执行操作。(我个人使用它),我从我的所有项目中创建一个包,并将其发送给客户,因此我使用主 pom 构建它们,并使用其他 maven 插件将它们打包为 zip 文件。