Maven多模块项目设置具有各种不同的依赖关系

时间:2014-02-27 21:02:06

标签: maven maven-3 maven-release-plugin multi-module

我先说一下:我是Maven的新手。那说我四处搜寻,但没有找到以下问题的答案。我找到了类似问题的答案,而不是这种情况。或者我可能只是误解了答案,这可以通过多模块设置简单地解决。

我有以下依赖层次结构:

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

我想让它工作,以便更改只会导致任何“上游”模块/应用程序的新版本。这确实是多模块maven设置的简单情况,还是我需要做其他事情?

1 个答案:

答案 0 :(得分:1)

如果您希望发布一个组件生成每个项目的新版本,只需使用http://maven.apache.org/maven-release/maven-release-plugin/

文档

根据文档,这将:

  
      
  • 检查来源中没有未提交的更改
  •   
  • 检查是否没有SNAPSHOT依赖项
  •   
  • 将POM中的版本从x-SNAPSHOT更改为新版本(系统将提示您输入要使用的版本)
  •   
  • 转换POM中的SCM信息以包含标记的最终目的地
  •   
  • 针对修改后的POM运行项目测试以确认一切正常[/ li>]   
  • 提交修改后的POM
  •   
  • 使用版本名称标记SCM中的代码(将提示)
  •   
  • 将POM中的版本转换为新值y-SNAPSHOT(也会提示这些值)
  •   
  • 提交修改后的POM
  •   

由于maven多模块结构,它们被链接在一起,每个项目都会被碰到一个新版本。

简而言之,这将:

  • 移动版本1.0-SNAPSHOT - > 1.1-SNAPSHOT
  • tag 1.0
  • 生成1.0.jar(ou war或其他任何东西)

插件使用

假设已正确定义SCM,并配置了存储库和分发管理,只需添加这些行

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.4.2</version>
        <!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
        <configuration>
          <tagNameFormat>v@{project.version}</tagNameFormat>
        </configuration>
      </plugin>
      [...]
    </plugins>
    [...]
  </build>
  [...]
</project>

并致电

mvn release:prepare
mvn release:perform

继承与依赖

你可以考虑两个不同的Maven approches:

  • 继承,即父和多/子模块
  • 聚合,换句话说:使用依赖项

在多个maven项目中,所有模块(包括父模块)共享相同的生命周期。释放一个暗示释放所有,因此,释放一个是没有意义。

在您的情况下,您无法在不影响应用4的情况下修改应用1至3。 如果App 4依赖App 1,显然App 1不能依赖于App 4(不允许循环引用)。

所以,你想要将App4和App1隔离到3个生命周期,你不应该使用多模块,而只是共享一个父项目,或者像公司&gt;那样的pom层次。主要项目&gt;子项目(不是子模块)。 之后,只需声明App 4和App 1之间的依赖关系(...到app4 pom.xml)

另一个想法:你的项目和子模块的名称听起来很奇怪。 “经典”层次结构通常是(考虑大型项目的多业务对象域):

Main Project (sometimes EAR) --> POM 
|-- Business Object / DAO --> POM
|   |-- Domain 1 --> JAR
|   `-- Domain 2 --> JAR
|-- Core (depends on BO)  --> JAR
`-- IHM / Web App (depends on core)  --> WAR

因此,数据库很少位于层次结构的顶层。