代码之家 › 专栏 › 技术社区 › Mark Derricutt

如何正确设置具有滑动发布周期的多模块Maven项目

intellij-idea maven-2 java

Mark Derricutt · 技术社区 · 17 年前

我正试图找出最好的方法来设置我们的多模块ApacheMaven项目,这种方法允许不同的模块发布周期,并且在调试项目时不会引入依赖性问题。

我们目前有一个沿着以下路线的设置:

BigStand @ 1.2
- 父-1.1-快照
- 模块A@1.4-快照
  - 父级@1.1-快照
- 模块B@1.3-快照
  - 父级@1.1-快照
  - 取决于a@1.1
- 模块C@1.1-快照
  - 父级@1.1-快照
  - 取决于a@1.2
  - 取决于b@1.1

模块B和C中声明的依赖项包含编译模块所需的最低版本,不一定是模块的当前版本,也不一定是正在部署的模块版本。

从构建的角度来看,这很好地工作,每个模块都可以根据需要发布/更新,但是当尝试在Intellij IDEA(版本8和9 EAP)下调试已部署的应用程序时,IDEA决定,由于我们声明了对@1.2的依赖性,因此每当我们进入A的某个类时,它应该从-1.2-sources.jar,而不是项目中当前的a@1.4源。这进一步被这样一个事实所迷惑:进入B的任何一个类都会把我们带到B@1.1而不是B@1.3。

我最初的尝试是在父POM的DependencyManagement部分中声明版本号,并让子模块继承该版本。这在一定程度上解决了IDEA调试问题,因为DependencyManagement部分可以将每个人指向当前的快照版本。

不幸的是,在执行maven发布时,这会导致一个问题,因为在释放模块之前必须释放父pom,但是正如父级可能引用开发中的多个快照一样,它不能被释放,最后我们将版本引用添加回模块pom以满足发布。

似乎使用Maven的DependencyManagement部分只会在我们同时释放所有捆绑包的情况下非常有效,不管它们是否发生了变化,但是因为我们只想在需要时管理每个子模块的发布,所以这个模型似乎不适合。

我怀疑我遗漏了一些东西,并且DependencyManagement和版本范围的组合可能满足需求,尽管我还没有看到版本范围正常工作。

有更好的方法吗?正确的方法?

4 回复 | 直到 16 年前

Rob Di Marco 17 年前

我建议不要让它们成为模块,而是让它们的POM独立。这样您就不必担心试图满足父POM依赖性。因为它们是独立发布的,所以它们确实应该有独立的项目对象模型。把ApacheCommons看作一个模板。

DavidValeri 17 年前

我认为IDEA的问题出现是因为您在源代码结构中使用根POM来做两件在Maven中通常是互斥的事情。您首先将POM用作存储无关(从构建的角度)Maven项目的公共配置信息的位置。其次,您使用POM作为构建的聚合器。你可以在不做其他事情的情况下做每一件事。

正如Rob所说,从父POM的模块部分删除模块A、B等项目。其次,将您的父POM向下移动到它自己的目录中,因为它实际上是与您的构建和发布过程相关的其他模块的兄弟。现在的情况是,它更像是一个父/聚合器。

现在的方法也不适合单独标记和释放每个模块,因为父POM的标记可能不必要地包括所有模块子文件夹。

您的文件结构如下:

起源
- XML
模块A
- XML
模块X
- XML

至于您缺少的东西,DependencyManagement实际上并不适合管理项目内部依赖项的版本。这是聚合生成中模块之间的依赖关系。它更适合为外部依赖项声明全局版本。

Mark Derricutt 16 年前

我们最终使用的最终/工作解决方案与我们开始使用的方案相当相似。实际项目结构保持不变:

BigStand @ 1.2
- 父-1.1-快照
- 模块A@1.4-快照 o父级@1.1-快照
- 模块B@1.3-快照 o父级@1.1-快照 o取决于a@1.1
- 模块C@1.1-快照 o父级@1.1-快照 o取决于a@1.2 o取决于b@1.1
- 分发A@1.2-Snapshop

但主要区别在于:

父模块不包含任何版本的 项目工件
各个模块完全声明它们的项目依赖性并指定一个版本范围,即[1.0.0,1.1.0]
所有模块都从.1开始,即1.0.1-snapshot版本号周期,这允许初始快照满足版本范围(1.0.0-snapshot早于1.0.0-final,因此不包括在内)。
分发pom(最初未显示在问题中)标识 准确的 要部署/包含在特定版本中的版本。
在发布时从本地Maven存储库中删除所有项目-快照,以便范围仅限于拾取发布(或对新的本地repo使用-dmaven.repo.local=/tmp/sometemprepo)

这使得每个模块更加独立,并让我们可以自由地发布和部署我们的项目工件的新版本,而不必大惊小怪。

Nick Veys 17 年前

它们看起来确实是独立的模块。如果它们有不同的依赖关系,即使在多模块项目中,您将它们粉碎在一起会获得什么好处?