目录
dependencies与dependencyManagement的区别
plugins 和 pluginManagement 的区别
在pom.xml中使用distributionManagement 将项目打包上传到nexus私服
dependencies与dependencyManagement的区别
1、DepencyManagement应用场景
当我们的项目模块很多的时候,我们使用Maven管理项目非常方便,帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。
由于我们的模块很多,所以我们又抽象了一层,抽出一个itoo-base-parent来管理子项目的公共的依赖。为了项目的正确运行,必须让所有的子项目使用依赖项的统一版本,必须确保应用的各个项目的依赖项和版本一致,才能保证测试的和发布的是相同的结果。
在我们项目顶层的POM文件中,我们会看到dependencyManagement元素。通过它元素来管理jar包的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用在这个dependencyManagement元素中指定的版本号。
- Dependencies
相对于dependencyManagement,所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
- 区别
dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)
dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom;另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。
<dependencies>中的jar直接加到项目中,管理的是依赖关系(如果有父pom,子pom,则子pom中只能被动接受父类的版本);<dependencyManagement>主要管理版本,对于子类继承同一个父类是很有用的,集中管理依赖版本不添加依赖关系,对于其中定义的版本,子pom不一定要继承父pom所定义的版本。
plugins 和 pluginManagement 的区别
plugins 和 pluginManagement 的区别,和我们前面研究过的 dependencies 和 dependencyManagement 的区别是非常类似的
假如存在两个项目,项目A为项目B的父项目,其关系通过pom文件的关系确定。项目A的父pom文件片段如下:
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1</version>
<configuration>
<attach>true</attach>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
如果项目B也想使用该plugin配置,则在项目B的子pom文件中只需要如下配置:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
快照版本和release版本区别
maven会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本,那么在mvn deploy时会自动发布到快照版本库中,而使用快照版本的模块,在不更改版本号的情况下,直接编译打包时,maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本,那么在mvn deploy时会自动发布到正式版本库中,而使用正式版本的模块,在不更改版本号的情况下,编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
所以,我们在开发阶段,可以将公用库的版本设置为快照版本,而被依赖组件则引用快照版本进行开发,在公用库的快照版本更新后,我们也不需要修改pom文件提示版本号来下载新的版本,直接mvn执行相关编译、打包命令即可重新下载最新的快照库了,从而也方便了我们进行开发。
在pom.xml中使用distributionManagement 将项目打包上传到nexus私服
!-- 使用分发管理将本项目打成jar包,直接上传到指定服务器 -->
<distributionManagement>
<!--正式版本-->
<repository>
<!-- nexus服务器中用户名:在settings.xml中<server>的id-->
<id>yang</id>
<!-- 这个名称自己定义 -->
<name>Release repository</name>
<url>http://192.168.1.122:8081/repository/yang/</url>
</repository>
<!--快照
<snapshotRepository>
<id>nexus-snapshots</id>
<name>Snapshots repository</name>
<url>http://192.168.1.122/repository/yang/</url>
</snapshotRepository>-->
</distributionManagement>
< repository >节点下的< id >对应setting.xml文件中的server的id
<!--maven连接nexus需要验证用户名和密码-->
<server>
<id>yang</id>
<username>admin</username>
<password>admin123</password>
</server>
多环境配置:profiles节点
1)在pom文件中配置如下:
<profiles>
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<env>test</env>
</properties>
</profile>
<profile>
<id>uat</id>
<properties>
<env>uat</env>
</properties>
</profile>
<profile>
<id>prd</id>
<properties>
<env>prd</env>
</properties>
</profile>
</profiles>
2)效果:
可以选择不同的环境 打包不同的资源文件
3)其中properties节点 可以在其他地方引用
这个配置的目的是把相应的资源文件打包到“targetPath” 目录下 默认打包到classes目录下
maven内置属性变量
${basedir} 项目根目录
${project.build.directory} 构建目录,缺省为target
${project.build.outputDirectory} 构建过程输出目录,缺省为target/classes
${project.build.finalName} 产出物名称,缺省为${project.artifactId}-${project.version}
${project.packaging} 打包类型,缺省为jar
${project.xxx} 当前pom文件的任意节点的内容