- 解决依赖冲突
- 引用变量的三种情况(maven命令)
- 多环境属性过滤
- 各种依赖(POM文件详解)
解决maven传递依赖中的版本冲突
传递依赖是maven最有特色的、最为方便的优点之一,可以省了很多配置。如a 依赖 b,b 依赖c 默认 a也会依赖 c。但是 也会带来隐患,如版本冲突。当然maven也考虑到解决办法,可以使用exclusions来排除相应的重复依赖。
但是我们还会遇到一个严重的问题,那就是,我怎么知道是哪个包的传递依赖产生的冲突 ?那该怎么办呢?当然,maven也会有相应的解决方案。
首先,你要在pom.xml中加上maven-project-info-reports-plugin插件。
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>
maven-project-info-reports-plugin
</artifactId>
</plugin>
</reporting>
然后再执行:mvn project-info-reports:dependencies 。生成项目依赖的报表,这样你就能够在报表中找出你版本冲突的相关性依赖了。
最后在相应的dependency中加上exclusions来排除相关的传递依赖。
例:
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>1.1.1</version>
<exclusions>
<exclusion>
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
</exclusion>
</exclusions>
<scope>runtime</scope>
</dependency>
----------------------------------------------------------
maven中内置隐式变量的使用:
1、引用pom.xml的project下的标签元素
引用pom.xml的project根标签下的自标签
例如:${project.groupId}
${project.artifactId}
使用maven命令查看pom.xml的完整信息
1.${project.build.directory} 构建目录,缺省为target
2.${project.build.outputDirectory} 构建过程输出目录,缺省为target/classes
3.${project.build.finalName} 产出物名称,缺省为
${project.artifactId}-${project.version}
4.${project.packaging} 打包类型,缺省为jar
5.${project.xxx} 当前pom文件的任意节点的内容
6.${basedir} 项目根目录
maven命令
2、引用maven的settings.xml中的元素
(默认settings.xml的路径:~/.m2/settings.xml)
使用方式:
${settings.offline}会引用~/.m2/settings.xml文件中offline元素的值。
3、引用系统环境变量的属性
使用方式:${env.PATH}——会被操作系统中的环境变量替换
----------------------------------------------------------
1、配置文件:“test.properties”,里面随便来上一行,例如Hello ${user.name}
2、<build>
<!--第一种方式,两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<build>
3、编译我们的maven项目
$mvn clean compile -Duser.name=tom
查看输出文件 target/classes/test.properties 的内容,可见原先的
“Hello {user.name}” 已经变成 “Hello Tom”。
<build>
<!--第二种方式,两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<filters>
<!-- 是以该pom文件路径作为参考 -->
<filter>project.properties</filter>
</filters>
<build>
profile功能:允许在项目文件(pom.xml)里面定义若干个profile段,然后在编译时选择
其中的一个用于覆盖项目文件原先的定义。
<build>
<!--第一种方式,两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<profiles>
<profile>
<id>dev</id>
<activation>
<!--默认的编译选项 -->
<activeByDefault>true</activeByDefault>
</activation>
<build>
<filters>
<filter>pre.properties</filter>
</filters>
</build>
</profile>
<profile>
<id>pre</id>
<build>
<filters>
<filter>dev.properties</filter>
</filters>
</build>
</profile>
</profiles>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<version>2.5</version>
</configuration>
</plugin>
</plugins>
</build>
在编译项目时,可以使用 -P 参数指定需要使用的 profile 的 id,比如下面命令将会使用
dev profile:$mvn clean compile -P dev
如果想使用pre,只需要改为以下即可
$mvn clean compile -Ppre
假如不指定 -P 参数的话,则会使用 activeByDefault=true 的一项(即 pre)。
----------------------------------------------------------
<modelVersion>4.0.0</modelVersion>
<!-- 模型版本。maven2.0必须是这样写,现在是maven2唯一支持的版本 -->
<groupId>com.ali.aa</groupId>
<!-- 公司或者组织的唯一标志,并且配置时生成的路径也是由此生成, 如com.ali.aa,
maven会将该项目打成的jar包放本地路径:/com/ali/aa -->
<artifactId>core</artifactId>
<!-- 本项目的唯一ID,一个groupId下面可能多个项目,就是靠artifactId来区分的 -->
<version>1.0.0-SNAPSHOT</version>
<!-- 本项目目前所处的版本号 -->
<packaging>jar</packaging>
<!-- 打包的机制,如pom,jar, maven-plugin, ejb, war, ear, rar, par,
默认为jar -->
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.3</version>
</dependency>
commons类库详解
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>${commons-io.version}</version>
</dependency>
Commons io--IOUtils
Commons之Commons-io
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>${commons-lang3.version}</version>
</dependency>
commons-lang3方法应用
commons-lang3工具类的学习
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
httpcomponents介绍和使用
学习笔记1
学习笔记2
httpcomponents之httpclient发送http请求
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>${httpclient.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
</exclusions>
</dependency>
commons codec基本使用
使用Commons codec 加密
Commons codec使用介绍
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>${commons-collections.version}</version>
</dependency>
集合工具类的使用
commons-collections之Map
----------------------------------------------------------
build部分
lifecycle:生命周期,这是maven最高级别的的控制单元,它是一系列的phase组成,也就
是说,一个生命周期,就是一个大任务的总称,不管它里面分成多少个子任务,反正就是运
行一个lifecycle,就是交待了一个任务,运行完后,就得到了一个结果,中间的过程,是
phase完成的,自己可以定义自己的lifecycle,包含自己想要的phase
phase:可以理解为任务单元,lifecycle是总任务,phase就是总任务分出来的一个个子任
务,但是这些子任务是被规格化的,它可以同时被多个lifecycle所包含,一个lifecycle可
以包含任意个phase,phase的执行是按顺序的,一个phase可以绑定很多个goal,至少为一
个,没有goal的phase是没有意义的
goal: 这是执行任务的最小单元,它可以绑定到任意个phase中,一个phase有一个或多个
goal,goal也是按顺序执行的,一个phase被执行时,绑定到phase里的goal会按绑定的时
间被顺序执行,不管phase己经绑定了多少个goal,你自己定义的goal都可以继续绑到
phase中。
官方文档:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.
html
http://maven.apache.org/ref/3.3.9/maven-core/lifecycles.html
mojo: lifecycle与phase与goal都是概念上的东西,mojo才是做具体事情的,可以简单理
解mojo为goal的实现类,它继承于AbstractMojo,有一个execute方法,goal等的定义都
是通过在mojo里定义一些注释的anotation来实现的,maven会在打包时,自动根据这些
anotation生成一些xml文件,放在plugin的jar包里
网友评论