如何使用滑动释放循环正确设置多模块Maven项目

时间:2009-07-31 00:59:19

标签: java maven-2 intellij-idea

我正在尝试以允许模块的不同发布周期的方式设置我们的多模块Apache Maven项目的最佳方法,并且在调试项目时不会引入依赖性问题。

我们目前的设置方式如下:

  • bigsystem@1.2
    • 父 - 1.1-SNAPSHOT
    • 模块a@1.4-SNAPSHOT
      • 由parent@1.1-SNAPSHOT提供的父母
    • module b@1.3-SNAPSHOT
      • 由parent@1.1-SNAPSHOT提供的父母
      • 取决于a@1.1
    • module c@1.1-SNAPSHOT
      • 由parent@1.1-SNAPSHOT提供的父母
      • 取决于a@1.2
      • 取决于b@1.1

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

从构建角度来看,这很有效,每个模块都可以根据需要发布/更新,但是当尝试在已打开顶级pom的IntelliJ IDEA(版本8和9 EAP)下调试已部署的应用程序时,IDEA决定我们声明了对a@1.2的依赖,任何时候我们进入其中一个类,它应该从a-1.2-sources.jar而不是项目中当前的a@1.4源打开它。这进一步混淆了这样一个事实,即进入任何一个班级需要我们到b@1.1而不是b@1.3。

我最初尝试解决这个问题是在父pom的dependencyManagement部分中声明版本号,并让子模块继承该版本。这有助于解决IDEA调试问题,因为dependencyManagement部分可以指向每个人当前的-SNAPSHOT版本。

由于必须在释放模块之前释放父pom,因此不幸导致maven发布时出现问题,但由于父级可能会引用多个in-development -SNAPSHOTS,因此无法释放它,我们最终会添加版本引用回到模块pom以满足发布。

似乎使用maven的dependencyManagement部分只有在我们同时发布ALL bundle时才能正常工作,无论它们是否发生了变化,但是因为我们只想在需要时管理每个子模块的版本模型似乎不适合。

我怀疑我遗漏了什么,并且dependencyManagement和版本范围的组合可能满足要求,尽管我还没有看到版本范围正常工作。

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

4 个答案:

答案 0 :(得分:4)

我建议不要制作模块,但要让它们的POM独立。这样您就不必担心尝试满足父POM依赖项。由于它们是独立发布的,因此它们应该具有独立的项目对象模型。将Apache Commons视为模板。

答案 1 :(得分:2)

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

像Rob说的那样,从父POM的模块部分删除你的模块a,b等项目。其次,将您的父POM移动到它自己的目录中,因为它实际上是构建和发布过程中其他模块的兄弟。现在的方式,它更像是父/聚合器。

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

您的文件结构如下:

    • 的pom.xml
  • 模块a
    • 的pom.xml
  • 模块X.
    • 的pom.xml

至于你缺少的东西,dependencyManagement不太适合管理项目内依赖项的版本。这是聚合构建中的模块之间的依赖关系。它更适合声明外部依赖项的全局版本。

答案 2 :(得分:2)

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

  • bigsystem@1.2
    • 父 - 1.1-SNAPSHOT
    • 模块a@1.4-SNAPSHOT   o由parent@1.1-SNAPSHOT提供父母身份
    • module b@1.3-SNAPSHOT   o由parent@1.1-SNAPSHOT提供父母身份   o取决于a@1.1
    • module c@1.1-SNAPSHOT   o由parent@1.1-SNAPSHOT提供父母身份   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,因此不包括在内)。
  • 分发pom(最初未显示有问题)标识要部署/包含在特定版本中的完全版本。
  • 在发布时从本地maven存储库删除所有项目-SNAPSHOTS,以便仅发布范围提取(或使用-Dmaven.repo.local = / tmp / sometemprepo获取新的本地存储库)

这使得每个模块更加独立,让我们可以自由地发布和部署项目工件的新版本,而且工作量极少。

答案 3 :(得分:0)

它们看起来像是单独的模块。如果它们具有不同的依赖关系,即使在多模块项目中,通过粉碎它们会获得什么好处?