maven知识点汇总详解

Maven坐标配置

一个maven项目的坐标可以包含如下配置：

    4.0.0
    com.qupeng.test.maven
    maven-coordinate
    Maven Coordinate
    1.2.3-beta-1
    jar

除了上述元素，还有一个 特殊的元素:classifier。这个元素是不能直接定义的，要结合Maven Plugin使用。

Maven坐标详解

1. groupId
   一般对应项目名称。例如：com.qupeng.test.maven，项目名称是maven
2. artifactId
   一般对应模块名称。例如：maven-coordinate，模块名称是coordinate，一般还建议加上项目前缀
3. version
   模块版本。例如:1.2.0-beta-1，该版本号由4部分组成。表示maven项目的coordinate模块的架构版本是1，功能版本是2，增量版本是0，里程碑版本是beta-1。
   • 主版本
     项目重大架构变更时递增。
   • 次版本
     大范围的功能增加和变化时递增。
   • 增量版本
     重大Bug的修复。
   • 里程碑版本
     某一个版本的里程碑。
4. 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：压缩文件。
5. classifier
   用来定义项目附属构件或分类构件的坐标。classifier用来区分从同一个POM构建,但内容不同的构件，它是一些可选的和任意的字符串。如果classifier存在，则被附加到版本号之后，规则为: artifactId-version[-classifier].packaging，[-classifier]为可选。
   此元素的作用一般有两种：
   • 区分不同版本的JRE。例如一个构件既支持JDK1.4，又支持JDK1.5，而且不同的支持包含不同的内容，就需要添加一个classifier坐标属性，让客户端来选择使用基于哪一个JDK的版本。例如，对json-lib的引用，坐标就需要包含classifier元素，不然坐标是错误的。

     	 
     		net.sf.json-lib 
     		json-lib 
     		2.2.2 
     		jdk15 
     	 
     

     我认为项目的构建过程类似于下面的配置：

     	 
     		maven-compiler-plugin 
     		2.3.2 
     		 
     		1.5 
     		1.5 
     		UTF-8 
     		 
     	 
     

     打包配置应该是这样的

          
     		    ... 
     		     
     		    	 
     			    	org.apache.maven.plugins 
     			    	maven-jar-plugin 
     			    	2.6 
     			    	false 
     			    	true 
     			    	 
     			    	jdk15 
     			    	 
     			    	... 
     			    	... 
     		    	 
     		     
     		    
     	
     

   2. 为项目添加附属构件。 例如Maven中央仓库中的source和javedoc构件，对应的classifier为source和javedoc。如何添加classifier？这项工作我们并不能干涉，我想应该是由maven插件完成的。

Maven依赖配置

聊一聊Maven的依赖配置。一个依赖声明可以包含如下一些元素：

  
     
      net.sf.json-lib 
      json-lib 
      2.2.2
      jar
      compile
      false
      
        
          junit
          junit
        
      
      jdk15 
     
  

下面借来分别介绍这些元素。

1. groupId
   依赖的基本坐标，参见上一章节。

2. artifactId
   依赖的基本坐标，参见上一章节。

3. version
   依赖的基本坐标，参见上一章节。

4. type
   依赖类型，参见上一章节

5. scope
   依赖范围，有如下备选值：

   • compile
     编译依赖范围，对于编译、测试、运行三种classpath都有效，也就是在编译、测试、运行的时候都需要该依赖。

   • test
     测试以来范围。只对于测试classpath有效，只在测试的时候需要该依赖。典型的如junit。

   • provided
     已提供依赖范围。对于编译、测试两种classpath有效，运行时classpath无效。也就是在编译、测 试时候都需要该依赖，运行时不需要。典型的如servlet。

   • runtime
     运行时依赖范围。对于测试、运行两种classpath有效，编译classpath无效。在编译时不需要，典型的如jdbc驱动实现。

   • system
     系统依赖范围。与provided类似，唯一的不同是必须明确的指定被依赖的构件在系统中的路径。典型的如本地的jar包，没有导入仓库中，需要从本地引用。例如：

      
     	javax.sql 
     	jdbc-stdext 
     	2.0 
     	system 
     	${java.home}/lib/rt.jar 
     
     

   • import
     导入依赖范围。如果需要完全复制一个已经存在依赖配置，可以使用导入依赖范围，将其导入，节省重复的配置。一般被导入的构件类型为pom。例如：

      
     	com.qupeng.test.maven 
     	maven-parent 
     	1.2.3-beta-1 
     	pom 
     	import 
     
     

6. 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配置为false，这样Y对A，B就没有传递性依赖了，Y必须明确配置对A或B的依赖。

   例如：X依赖 mysql 和 postgresql

   	X
       
           
               mysql
               mysql-connector-java
               5.1.10
               true
           
           
               postgresql
               postgresql
               8.4-701.jdbc3
               true
           
       
   

   Y必须显式配置其中一个依赖：

   Y 
    
   	 
   		mysql 
   		mysql-connector-java 
   		5.1.10 
   		true 
   	 
    
   

7. exclusions exclusions
   用来排除传递依赖。例如有的传递性依赖的构件版本不稳定或与其他依赖有冲突，就可以使用exclusions元素来排除传递性依赖。

   
        
         net.sf.json-lib 
         json-lib 
         2.2.2
         jar
         compile
         false
         
           
             junit
             junit
           
         
         jdk15 
        
     
   

Maven依赖配置最佳实践

自动化的依赖引用很容易造成依赖重复，进而造成冲突。为了优化Maven依赖，我们需要了解Maven对重复依赖的调解的两个原则：

1. 路径最近优先
2. 第一声明者优先

常用技巧：

• 排除依赖
  参考上文中对excludions元素的描述

• 归类依赖
  使用Maven属性统一相同项目不同模块的依赖版本

      
          2.5.6
      
      
          
              org.springframework
              spring-core
              ${springframework.version}
          
          
              org.springframework
              spring-beans
              ${springframework.version}
          
          
              org.springframework
              spring-context
              ${springframework.version}
          
          
              org.springframework
              spring-context-support
              ${springframework.version}
          
      
  

• 优化依赖
  可以使用如下命令分析依赖树，并优化依赖树

  mvn dependency:list
  mvn dependency:tree
  mvn dependency:analyze

重点关注声明未使用和使用未声明的依赖，并进行修改。

原文：https://blog.csdn.net/yunyun1886358/article/details/54561743