笔记:Maven 反应堆

在一个多模块的Maven项目中,反应堆(Reactor)是指所有模块组成的一个构建结构,对于单个模块的项目,反应堆就是该模块本身,但对于多模块项目来说,反应堆就包含了各模块之间继承与依赖的关系,从而能够自动计算出合理的模块构建顺序,但有些时候,用户想要仅仅构建完整反应堆中的某些个模块,Maven
提供很多的命令行选项支持裁剪反应堆,裁剪参数列表如下:

  • -am,--also-make:同时构建所列模块的依赖模块
  • -amd,-also-make-dependents:同时构建依赖于所列模块的模块
  • -pl,--projects<arg>:构建指定的模块,模块间用逗号分隔
  • -rf,-resume-from<arg>:在完整的反应堆构建顺序基础上指定从哪个模块开始构建

使用示例:

  • 使用-pl来指定构建某几个模块,命令如下:

    mvn clean -pl account-service

    命令结果如下:

  • 使用-pl来指定构建某几个模块,并增加
    -am
    参数同时构建依赖的模块,命令如下:

    mvn clean -pl account-service -am

    命令结果如下:

  • 使用
    -amd
    选项可以同时构建依赖于所列模块的模块,命令如下:

    mvn clean -pl account-email
    -amd

    命令结果如下:

    使用
    -rl
    选项可以在完整的反应堆构建顺序基础上指定从哪个模块开始构建,命令如下:

    mvn
    clean
    -rf
    account-email

    命令结果如下:

    ?
    ?

时间: 2024-11-03 19:08:46

笔记:Maven 反应堆的相关文章

学习笔记——Maven实战(十)Maven 3,是时候升级了

去年10月份Apache Maven发布了3.0正式版,而在上个月的22号,Eclipse基金会宣布了Eclipse 3.7(Indigo)的发布,该版本Eclipse最大的新特性之一就是集成了Maven.下载Eclipse IDE for Java Developers版本的用户会发现,Eclipse已经能够自动识别Maven项目了.Indigo中内置的Maven版本是3.0.2,这在一定程度上说明Maven 3已经非常稳定了.不过我相信一定还有很多Maven 2用户在犹豫是否升级,本文会介绍

学习笔记——Maven超级POM

Maven有一个超级POM,所有的POM均继承此文件.该文件定义如下:<project>   <modelVersion>4.0.0</modelVersion>   <repositories>     <repository>       <id>central</id>       <name>Central Repository</name>       <url>http://

学习笔记——Maven settings.xml 配置详解

文件存放位置 全局配置: ${M2_HOME}/conf/settings.xml 用户配置: ${user.home}/.m2/settings.xml note:用户配置优先于全局配置.${user.home} 和和所有其他系统属性只能在3.0+版本上使用.请注意windows和Linux使用变量的区别. settings.xml详解 声明规范 <?xml version="1.0" encoding="UTF-8"?> <settings x

学习笔记——Maven实战(九)打包的技巧

“打包“这个词听起来比较土,比较正式的说法应该是”构建项目软件包“,具体说就是将项目中的各种文件,比如源代码.编译生成的字节码.配置文件.文档,按照规范的格式生成归档,最常见的当然就是JAR包和WAR包了,复杂点的例子是Maven官方下载页面的分发包,它有自定义的格式,方便用户直接解压后就在命令行使用.作为一款”打包工具“,Maven自然有义务帮助用户创建各种各样的包,规范的JAR包和WAR包自然不再话下,略微复杂的自定义打包格式也必须支持,本文就介绍一些常用的打包案例以及相关的实现方式,除了前

学习笔记——Maven实战(五)自动化Web应用集成测试

自动化集成测试的角色 本专栏的上一篇文章讲述了Maven与持续集成的一些关系及具体实践,我们都知道,自动化测试是持续集成必不可少的一部分,基本上,没有自动化测试的持续集成,都很难称之为真正的持续集成.我们希望持续集成能够尽早的暴露问题,但这远非配置一个 Hudson/Jenkins服务器那么简单,只有真正用心编写了较为完整的测试用例,并一直维护它们,持续集成才能孜孜不倦地运行测试并第一时间报告问题. 自动化测试这个话题很大,本文不想争论测试先行还是后行,这里强调的是测试的自动化,并基于具体的技术

学习笔记——Maven实战(七)常用Maven插件介绍(上)

我们都知道Maven本质上是一个插件框架,它的核心并不执行任何具体的构建任务,所有这些任务都交给插件来完成,例如编译源代码是由maven-compiler-plugin完成的.进一步说,每个任务对应了一个插件目标(goal),每个插件会有一个或者多个目标,例如maven-compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码,testCompile目标用来编译位于src/test/java/目录下的测试源码. 用户可以通过两种方式调用Maven插

学习笔记——Maven pom.xml配置详解

POM的全称是“ProjectObjectModel(项目对象模型)”. pom.xml详解 声明规范 <projectxmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apach

学习笔记——Maven实战(六)Gradle,构建工具的未来?

Maven面临的挑战 软件行业新旧交替的速度之快往往令人咂舌,不用多少时间,你就会发现曾经大红大紫的技术已经成为了昨日黄花,当然,Maven也不会例外.虽然目前它基本上是Java构建的事实标准,但我们也能看到新兴的工具在涌现,比如基于Goovy的Gradle,而去年Hibernate宣布从Maven迁移至Gradle这一事件更是吸引了不少眼球.在此之前,我也听到了不少对Maven的抱怨,包括XML的繁冗,不够灵活,学习曲线陡峭等等.那Gradle是否能够在继承 Maven优点的基础上,克服这些缺

学习笔记——Maven 如何处理传递性依赖

maven引入的传递性依赖机制,一方面大大简化和方便了依赖声明,另一方面,大部分情况下我们只需要关心项目的直接依赖是什么,而不用考虑这些直接依赖会引入什么传递性依赖.但有时候,当传递性依赖造成问题的时候,我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的. 例如,项目A有这样的依赖关系 : A-->B-->C-->X(1.0).A-->D-->X(2.0),X是A的传递性依赖,但是两条依赖路径上有两个版 本的X,那么哪个X会被maven解析使用呢?两个版本都被解析显然是不