考虑以下企业应用程序分层示例：
在Maven中组织此操作的正确方法是什么？我应该创建一个多模块maven项目吗？如果'project-services'是一个Maven模块，它是否可以与其他三个项目共享，每个项目都是一个独立的可部署单元？
在我之前的项目中，我只创建了4个不同的Maven项目，从来没有太多需要其他任何东西。
想要验证是否有比以前更好的方式。
答案 0 :(得分：2)
你实际上可以做任何一种方法。如果它真的是一个大项目，你总是希望同时构建和发布，那么多模块项目是一个很好的选择。你可能会这样设置：
pom project (top level project that would define all of the modules)
jar project (project-services)
war project (project-web)
war project (project-web-services)
project-standalone (wasn't sure if this was a jar, or just some scripts, etc)
因此，您只需构建和发布根项目，并为您处理所有子模块。它们每个都可以相互依赖（只需要注意循环依赖）。而你几乎已经准备好了。
另一个选项是单独的工件。这样做的好处是有不同的发布周期。这是一个很好的选择，当你有一个不经常改变的jar库，但你经常更新战争。
显然，你可以混合，所以也许jar是独立的，但是你有一个包含两个war文件的多模块项目。 maven的好处在于它足够灵活，可以处理您应该如何分割这些内容的商业案例。答案 1 :(得分：1)
在我的工作场所，我们有许多共享图书馆的顶级项目（15个顶级项目共享35个左右的图书馆）。我们采用了每个图书馆方法的单一项目。今天，当我们不得不一次性释放所有这些时，这是一场噩梦。
我们面临的一些问题：
如果我不得不重新开始（我帮助设置了所有这些），我会使用一个单模块项目。如果不出意外，一次性释放一切都是一个巨大的优势。这些项目在日食中可能看起来不太漂亮，但这不是你应该瞄准的目标。
答案 2 :(得分：0)
我肯定会选择一个带有模块的项目，以确保常用第三方库的使用版本匹配。
将POM项目作为根并且所有实现和其他人工制品共享它通常被认为是除了单模块项目之外的所有项目的良好实践。
答案 3 :(得分：0)
由于模块之间存在一些直接依赖关系，我还建议在多模块项目中使用。
我经常建议考虑模块的生命周期。例如：如果您将比服务层更频繁地释放批处理模块，则将它拆分可能是有意义的。所以你不需要发布（部署）没有变化的东西。 由于批处理通常不像.war文件那样部署。但这取决于服务+批处理模块的生命周期。
在大多数情况下，并排移动。所以+1为“一劳永逸”