首页 > 代码库 > Maven学习笔记(十一):灵活的构建
Maven学习笔记(十一):灵活的构建
典型的项目会有开发环境、测试环境和产品环境,这些环境的数据库配置不尽相同,那么项目构建的时候就需要能够识别所在的环境并使用正确的配置。还有一种情形是,项目开发了大量的集成测试,这些测试运行起来非常耗时,不适合在每次构建项目的时候都运行,因此需要一种手段能让我们在特定的时候才激活这些集成测试。Maven为了支持构建的灵活性,内置了三大特性,即属性、Profile和资源过滤。本章将介绍这些特性。
Maven属性
Maven的六类属性:
Maven一共有六类属性,分别是:
1. 内置属性:主要有两个常用内置属性-${basedir}表示项目根目录,即包含pom.xml文件的目录;${version}表示项目的版本。
2. POM属性:用户可以使用该类属性引用POM文件中对应元素的值。例如${project.artifactId}就对应了<project><artifactId>元素的值,常用的POM属性包括:
2. POM属性:用户可以使用该类属性引用POM文件中对应元素的值。例如${project.artifactId}就对应了<project><artifactId>元素的值,常用的POM属性包括:
- ${project.build.sourceDirectory}:项目的主源码目录,默认为src/main/java/。
- ${project.build.testSourceDirectory}:项目的测试源码目录,默认为src/test/java/。
- ${project.build.directory}:项目构建输出目录,默认为target/。
- ${project.outputDirectory}:项目的主代码编译输出目录,默认为target/classes/。
- ${project.testOutputDirectory}:项目测试代码编译输出目录,默认为target/test-classes/。
- ${project.groupId}:项目的groupId。
- ${project.artifactId}:项目的artifactId。
- ${project.version}:项目的version。
- ${project.build.finalName}:项目打包输出文件的名称,默认为${project.artifactId}-${project.version}。
这些属性都对应了一个POM元素,它们中的一些属性的默认值是在超级POM中定义的。
3. 自定义属性:用户可以在POM的<properties>元素下自定义Maven属性。例如:
<project> ... <properties> <my.prop>hello</my.prop> </properties> ... </project>
然后在POM中其他地方使用${my.prop}的时候会被替换成hello。
4. Settings属性:与POM属性同理,用户使用以settings.开头的属性引用settings.xml文件中XML元素的值,如常用的${settings.localRepository}指向用户本地仓库的地址。
5. Java系统属性:所有Java系统属性都可以使用Maven属性引用,例如${user.home}指向了用户目录。用户可以使用mvn help:system查看所有的Java系统属性。
6. 环境变量属性:所有环境变量都可以使用以env.开头的Maven属性引用。例如${env.JAVA_HOME}指代了JAVA_HOME环境变量的值。用户可以使用mvn help:system查看所有的Java系统属性。
使用范例:
在一个多模块项目中,模块之间的依赖比较常见,这些模块通常会使用同样的groupId和version,这个时候就可以使用POM属性。
<dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>account-email</artifacId> <version>${project.version}</version> </denpendency> <dependency> <groupId>${project.groupId}</groupId> <artifactId>account-persist</artifacId> <version>${project.version}</version> </denpendency> </dependencies>
通常,甚至该子模块的groupId和version也在聚合模块中约定好,那么现在这几个模块的groupId和version就做到了完全的一致。
构建环境的差异:
在不同的环境中,项目的源码应该使用不同的方式进行构建。例如,我们在开发环境可能使用一套数据库配置,在线上环境可能使用另外一套数据库配置,相似的,对于缓存的配置、对于其他应用的RFC链接都可能在不同的生产环境下有不同的配置。
资源过滤:
为了应对环境的变化,我们需要将会发生变化的部分提取出来。例如对于数据库的配置来说,我们一般会在src/main/resources目录下添加数据库的配置文件.properties文件。连接数据库使用的驱动类、URL、用户名和密码都可能发生变化,因此用Maven属性取代它们:
database.jdbc.driverClass=${db.driver}database.jdbc.connectionURL=${db.url}database.jdbc.username=${db.username}database.jdbc.password=${db.password}
既然使用了Maven属性,我们就需要定义他们,在这里我们需要用到profile将其包裹起来,针对项目的不同配置,我们应该把profile定义在POM中。
<profiles> <profile> <id>dev</id> <properties> <db.driver>com.mysql.jdbc.Driver</db.driver> <db.url>jdbc:mysql://192.168.1.100:3306/test</db.url> <db.username>dev</db.username> <db.password>dew-pwd</db.password> </properties> </profile> </profiles>
这里将这个profile命名为dev是为了将开发环境下的配置与其他环境区别开来。
在默认情况下,Maven属性只会在POM中被解析,现在我们需要的是其在资源文件中也要被解析,因此我们需要定制maven-resources-plugin的行为,使其在处理资源文件时,能够对Maven属性进行过滤,即开启资源过滤。
为主资源目录开启过滤:
<resources> <resource> <directory>${project.basedir}/src/main/resources</directory> <filtering>true</filtering> </resource> </resouces>
为测试资源开启过滤:
<testResources> <testResource> <directory>${project.basedir}/src/test/resources</directory> <filtering>true</filtering> </testResource> </testResouces>
主资源目录和测试资源目录都可以超过一个,Maven允许用户声明多个资源目录,并且为每个资源目录提供不同的过滤配置。
<resources> <resource> <directory>${project.basedir}/src/main/resources</directory> <filtering>true</filtering> </resource> <resource> <directory>/src/main/sql</directory> <filtering>false</filtering> </resource> </resouces>
最后我们只需要在使用mvn的时候,在命令行激活profile,Maven就能够在构建项目的时候使用profile中属性值替换数据库配置文件中的属性引用,命令如下:
$mvn clean install -Pdev
mvn的- P参数表示在命令行激活一个profile。这里激活了id为dev profile。可以在处理完之后的资源文件中看到,所有maven属性都已经被替换了过来。
Maven profile:
在不同环境下的构建很可能是不同的,典型的情况就是数据库的配置。除此之外,有些环境可能需要配置插件执行一些特殊的操作,或者使用特殊版本的依赖,或者需要一个特殊的构件名称。为了能让构建在各个环境下方便地移植,Maven引入了profile的概念。profile能够在构建的时候修改POM的一个子集,或者添加额外的配置元素。用户可以使用很多方式激活profile,以实现构建在不同环境下的移植。
激活profile:
1 .命令行激活
用户可以使用mvn命令行参数-P加上profile的id来激活profile,多个id之间以逗号分隔。例如,下面的命令激活了dev-x和dev-y两个profile:
$mvn clean install -Pdev-x, dev-y
2.settings文件显式激活
如果用户希望某个profile默认一直处于激活状态,就可以配置settings.xml文件的activeProfiles元素,表示其配置的profile对于所有项目都处于激活状态,代码如下:
<settings> ... <activeProfiles> <activeProfile>dev-x</activeProfile> </activeProfiles> </settings>
3 .系统属性激活
4. 操作系统环境激活
5. 文件存在是否激活
6. 默认激活
最下面的4种方式并不常用,因此不多做介绍。
Profile的种类:
根据具体的需要,可以在以下位置声明profile:
- pom.xml:很显然,pom.xml中声明的profile只对当前项目有效。
- 用户settings.xml:用户目录下.m2/settings.xml中的profile对本机上该用户所有的Maven项目有效。
- 全局settings.xml:Maven安装目录下conf/settings.xml中的profile对本机上所有的Maven项目有效。
为了不影响其他用户且方便升级Maven,用户应该选择配置用户范围的settings.xml,避免修改全局范围的settings.xml文件。也正是因为这个原因,一般不会在全局的settings.xml文件中添加profile。
不同类型的profile中可以声明的POM元素也是不同的,pom.xml中的profile能够随着pom.xml一起被提交到代码仓库中、被Maven安装到本地仓库中、被部署到远程Maven仓库中。换言之,可以保证该profile伴随着某个特定的pom.xml一起存在,因此它可以修改或者增加很多POM元素,见如下:
<project> <repositories></repositories> <pluginRepositories></pluginRepositories> <distributionManagement></distributionManagement> <dependencies></dependencies> <dependencyManagement></denpendencyManagement> <modules></modules> <properties></properties> <reporting></reporting> <build> <plugins></plugins> <defaultGoal></defaultGoal> <resources></resources> <testResources></testResources> <finalName></finalName> </build> </project>
由于settings.xml与具体项目无关,所以在其中可以配置的profile元素较少:
<project> <repositories></repositories> <pluginRepositories></pluginRepositories> <properties></properties> <project>
Maven学习笔记(十一):灵活的构建
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。