Maven坐标配置
一个maven项目的坐标可以包含如下配置：
<project xmlns="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.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.qupeng.test.maven</groupId>
<artifactId>maven-coordinate</artifactId>
<name>Maven Coordinate</name>
<version>1.2.3-beta-1</version>
<package>jar</package>
</project>
除了上述元素，还有一个 特殊的元素:classifier。这个元素是不能直接定义的，要结合Maven Plugin使用。
Maven坐标详解
- groupId
一般对应项目名称。例如：com.qupeng.test.maven，项目名称是maven - artifactId
一般对应模块名称。例如：maven-coordinate，模块名称是coordinate，一般还建议加上项目前缀 - version
模块版本。例如:1.2.0-beta-1，该版本号由4部分组成。表示maven项目的coordinate模块的架构版本是1，功能版本是2，增量版本是0，里程碑版本是beta-1。- 主版本
项目重大架构变更时递增。 - 次版本
大范围的功能增加和变化时递增。 - 增量版本
重大Bug的修复。 - 里程碑版本
某一个版本的里程碑。
- 主版本
- package
依赖的类型，对应于项目坐标定义的packaging，默认值为jar。可配置为如下类型：- pom：代表父模块或聚合模块。
- jar：一般的jar包模块，包含Java类的普通库、资源（resources）、辅助文件（auxiliary files）等。
- maven-plugin：maven插件模块。
- ejb：ejb应用模块。
- war：包含全部Web应用程序。在这种情形下，一个Web应用程序被定义为单独的一组文件、类和资源，用户可以对jar文件进行封装，并把它作为小型服务程序（servlet）来访问。
- ear：包含全部企业应用程序。在这种情形下，一个企业应用程序被定义为多个jar文件、资源、类和Web应用程序的集合。
- rar：压缩文件。
- par：压缩文件。
- classifier
用来定义项目附属构件或分类构件的坐标。classifier用来区分从同一个POM构建,但内容不同的构件，它是一些可选的和任意的字符串。如果classifier存在，则被附加到版本号之后，规则为: artifactId-version[-classifier].packaging，[-classifier]为可选。
此元素的作用一般有两种：- 区分不同版本的JRE。例如一个构件既支持JDK1.4，又支持JDK1.5，而且不同的支持包含不同的内容，就需要添加一个classifier坐标属性，让客户端来选择使用基于哪一个JDK的版本。例如，对json-lib的引用，坐标就需要包含classifier元素，不然坐标是错误的。
我认为项目的构建过程类似于下面的配置：<dependency> <groupId>net.sf.json-lib</groupId> <artifactId>json-lib</artifactId> <version>2.2.2</version> <classifier>jdk15</classifier> </dependency>
打包配置应该是这样的<plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.5</source> <target>1.5</target> <encoding>UTF-8</encoding> </configuration> </plugin><build> ... <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.6</version> <extensions>false</extensions> <inherited>true</inherited> <configuration> <classifier>jdk15</classifier> </configuration> <dependencies>...</dependencies> <executions>...</executions> </plugin> </plugins> </build>
- 为项目添加附属构件。 例如Maven中央仓库中的source和javedoc构件，对应的classifier为source和javedoc。如何添加classifier？这项工作我们并不能干涉，我想应该是由maven插件完成的。
- 区分不同版本的JRE。例如一个构件既支持JDK1.4，又支持JDK1.5，而且不同的支持包含不同的内容，就需要添加一个classifier坐标属性，让客户端来选择使用基于哪一个JDK的版本。例如，对json-lib的引用，坐标就需要包含classifier元素，不然坐标是错误的。
Maven依赖配置
聊一聊Maven的依赖配置。一个依赖声明可以包含如下一些元素：
<project xmlns="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.0 http://maven.apache.org/maven-v4_0_0.xsd">
<dependencies>
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.2.2</version>
<type>jar</type>
<scope>compile</scope>
<optional>false</optional>
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
<classifier>jdk15</classifier>
</dependency>
<dependencies>
</project>
下面借来分别介绍这些元素。
-
groupId
依赖的基本坐标，参见上一章节。 -
artifactId
依赖的基本坐标，参见上一章节。 -
version
依赖的基本坐标，参见上一章节。 -
type
依赖类型，参见上一章节 -
scope
依赖范围，有如下备选值：-
compile
编译依赖范围，对于编译、测试、运行三种classpath都有效，也就是在编译、测试、运行的时候都需要该依赖。 -
test
测试以来范围。只对于测试classpath有效，只在测试的时候需要该依赖。典型的如junit。 -
provided
已提供依赖范围。对于编译、测试两种classpath有效，运行时classpath无效。也就是在编译、测 试时候都需要该依赖，运行时不需要。典型的如servlet。 -
runtime
运行时依赖范围。对于测试、运行两种classpath有效，编译classpath无效。在编译时不需要，典型的如jdbc驱动实现。 -
system
系统依赖范围。与provided类似，唯一的不同是必须明确的指定被依赖的构件在系统中的路径。典型的如本地的jar包，没有导入仓库中，需要从本地引用。例如：<dependency> <groupId>javax.sql</groupId> <artifactId>jdbc-stdext</artifactId> <version>2.0</version> <scope>system</scope> <sustemPath>${java.home}/lib/rt.jar</sustemPath> </dependency> -
import
导入依赖范围。如果需要完全复制一个已经存在依赖配置，可以使用导入依赖范围，将其导入，节省重复的配置。一般被导入的构件类型为pom。例如：<dependency> <groupId>com.qupeng.test.maven</groupId> <artifactId>maven-parent</artifactId> <version>1.2.3-beta-1</version> <type>pom</type> <scope>import</scope> </dependency>
-
-
optional
依赖是否可选。要理解optional元素，必须理解传递性依赖。我们在为一个项目配置依赖的时候，被依赖的构件也很会依赖其他的构件，那么这些构件我们是不是也需要配置呢？答案肯定是不需要的，传递性依赖替我们解决了这个问题，它让我们只需要配置项目直接依赖的构件，而不需要关心这些构件的依赖关系。但是这种便利性也带来了一些副作用，例如依赖的冲突。所以maven又提供了一些机制，让我们可以在一定程度上控制传递依赖，optional就是其中一个。
我们还需要理解两个概念，第一直接依赖和第二直接依赖。假设A依赖B，B依赖C，那么A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖和第二直接依赖的范围决定了传递性依赖的范围。如下表，第一列是第一直接依赖范围，第一行是第二直接依赖范围，中间区域是传递依赖范围。第一直接依赖\第二直接依赖 compile test provided runtime compile compile - - runtime test test - - test provided provided - provided provided runtime runtime - - runtime 如果我们的模块X直接依赖A，B两个构件，但是依赖X的项目Y最终只依赖A，B中的一个，而不是两个都依赖，就可以在X中将A，B配置为
<optional>false</optional>，这样Y对A，B就没有传递性依赖了，Y必须明确配置对A或B的依赖。例如：X依赖 mysql 和 postgresql
<artifactId>X</artifactId> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.10</version> <optional>true</optional> </dependency> <dependency> <groupId>postgresql</groupId> <artifactId>postgresql</artifactId> <version>8.4-701.jdbc3</version> <optional>true</optional> </dependency> <dependencies>Y必须显式配置其中一个依赖：
<artifactId>Y</artifactId> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.10</version> <optional>true</optional> </dependency> <dependencies> -
exclusions exclusions
用来排除传递依赖。例如有的传递性依赖的构件版本不稳定或与其他依赖有冲突，就可以使用exclusions元素来排除传递性依赖。<dependencies> <dependency> <groupId>net.sf.json-lib</groupId> <artifactId>json-lib</artifactId> <version>2.2.2</version> <type>jar</type> <scope>compile</scope> <optional>false</optional> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> </exclusions> <classifier>jdk15</classifier> </dependency> <dependencies>
Maven依赖配置最佳实践
自动化的依赖引用很容易造成依赖重复，进而造成冲突。为了优化Maven依赖，我们需要了解Maven对重复依赖的调解的两个原则：
- 路径最近优先
- 第一声明者优先
常用技巧：
-
排除依赖
参考上文中对excludions元素的描述 -
归类依赖
使用Maven属性统一相同项目不同模块的依赖版本<properties> <springframework.version>2.5.6</springframework.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>${springframework.version}</version> </dependency> </dependencies> -
优化依赖
可以使用如下命令分析依赖树，并优化依赖树mvn dependency:list
mvn dependency:tree
mvn dependency:analyze
重点关注声明未使用和使用未声明的依赖，并进行修改。
原文：https://blog.csdn.net/yunyun1886358/article/details/54561743
扫一扫
260
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
