Maven多模块项目结构

Col*_*n M 12 java maven

我正在构建一个基于前端(读取:面向Web)的HTTP API的分布式应用程序,该API调用底层(读取:非面向Web的)Thrift服务.

举个例子,我可能有:

  • 身份验证服务(包含身份验证代码)
  • 核心服务(包含生成的thrift源和一些常见的类,如服务发现和初始化逻辑)

所有单独的服务都依赖于核心服务,HTTP面向Web的API也是如此.我现在将它作为一个多模块项目,但我希望每个项目都是独立的(并在他们自己的存储库中进行跟踪 - 尽管我知道我仍然可以通过多模块构建来实现这一点).

tl;博士 -

是一个常见的构建实践,有一个单独构建的模块(核心服务),然后推送到maven repo(然后作为jar包含在其他项目中),或者在这种情况下更好地做一个多模块项目?

Nic*_*olt 16

我个人试图避免多模块项目,因为如果您使用的是Maven Release Plugin,您将无法一起发布所有模块.

虽然这可能听起来很方便,当你需要对其中一个模块进行错误修复发布时,问题就出现了 - 你最终发布了所有模块,而不仅仅是带有错误修复的模块,即使它们还没有,也会增加它们的版本改变.

如果您正在使用多模块项目运行CI,那么您也会受到欢迎 - 您构建的内核通常会运行在您的根pom上的所有模块中,但如果您在特定模块中工作,那么您最终会成功构建这些模块没有改变,实际上失去了模块化意味着提供的一些好处.

因此,使用独立模块,但这是重要的一点,创建一个共同的'依赖'pom使用每个.

"依赖"pom是一个标准化项目中所有依赖项的pom,不同之处在于这些依赖项是在dependencyManagement部分而不是dependencies部分中指定的(它还设置了标准的插件配置等).这允许您的项目poms将依赖项pom指定为其父项,然后声明它们所需的依赖项减去版本,这些版本从"依赖项"pom中获取并因此在您的项目中标准化.

如果您仍然担心能够构建所有内容,可以使用简单的批处理文件来实现.

  • 只是对多模块项目使用的侧面评论 - 如果模块都有不同的生命周期,那么它们不应该是同一个多模块结构的一部分.@ colin-morelli应该在他的决定中考虑到这一点. (3认同)

Sta*_*avL 7

我会说多模块项目更好.如果将核心服务放在存储库中,开发人员应该关心版本.Developer1需要旧服务,但Developer2更新服务.

多个分支也可能是个问题.


wha*_*ley 5

当所有单个模块具有彼此相同的生命周期时,应该优先考虑多模块构建...换句话说,当它们总是一起发布时,它们的版本号一起增加等等.等等.

在OSS世界中有一个很好的例子就是apache camel项目.例如,所有捆绑组件都作为单独的模块存在,可以单独包含在项目中,但与camel核心分发相同的生命周期.

Maven多模块构建在将项目放入CI或在IDE中加载时允许一些方便,但一般来说,如果所有单个模块不共享相同的生命周期,那么多模块项目不是很合适