02 坐标和依赖

一、坐标
Maven中的坐标用来标识构件。Maven中的任意构件都有一个唯一的坐标,Maven可以通过这个坐标在仓库中查找相关构件,我们开发自己的项目时也需要一个坐标。
坐标由groupId、artifactid、version、packaging、classifier构成,如:

<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

 

1.groupId:
      定义当前Maven项目隶属的实际项目。首先,Maven和实际的项目不是一定的一一对应的关系。比如SpringFramework这个开源项目,由多个Maven项目如:spring-core、spring-context等。其次,groupId不应该对应到项目隶属的组织或公司。因为一个组织很可能会有多个实际项目。最后,groupId和表示方式和Java包名的表示方式类似。通常是域的反写。

 

2.artifactId
     定义实际项目中的一个Maven项目(模块),推荐的做法是使用实际项目的名称作为artifactId的前缀。这样的好处是方便寻找。

 


3.version
     定义Maven项目当前所处的版本。

 

4.packaging:(可选)
     定义Maven项目的打包方式。首先,打包方式通常与生成构件的文件扩展名对象。如上例生成的文件名为nexus-indexer-1.0.0.jar。使用war打包方式最终会生成一个.war文件。但这个不是绝对的。其次,打包方式会影响到项目构建的生命周期。例如jar打包和war打包会使用不同的命令。最后,当不定义packaging时,默认是jar。

 

5.classifer:(不可直接定义)
      该元素用来定义主构建的一些附属属性。附属属性与主构件对应。如上例中的nexus-indexer-1.0.0.jar是主构件。该项目还有一些附属构件如:nexus-indexer-1.0.0-source.jar、nexus-indexer-1.0.0-javadoc.jar。这时source和javadoc就是这两个构件的classifier。
注意:不能直接定义项目的classifer,因为附属构件项目的直接默认生成的,而是由附加的插件帮助生成的。

 

 

二、依赖
    声明依赖使用pom.xml的project根元素下dependencies元素。如:

 

    ...
	<dependencies>
		<dependency>
			<groupId>...</groupId>
			<artifactId>...</artifactId>
			<version>...</version>
			<type>...</type>
			<scope>...</scope>
			<optional>...</optional>
			<exclusions>
				<exclusion>
					...
				</exclusion>
				...
			</exclusions>
		</dependency>
		...
	</dependencies>
</project>

     每个dependencies可以包含任意个dependency元素,以声明一个一个依赖。每个依赖可用的属性有:
groupId、artifactId和version:依赖的基本坐标
type:依赖的类型,对应于项目坐标中的packaging。大部分情况下,该元素不必指定,其默认值是jar
scope:依赖范围
optional:标记依赖是否可选。
exclusions:用来排除传递性依赖。

 

 

三、依赖范围
      首先Maven在编译项目主代码时需要使用一套classpath;其实在编译的执行测试代码时会使用另一套classpath;最后,实际运行Maven项目时,又会使用一套classpath。
      依赖范围就是用来控制依赖与这三种classpath的关系。Maven有以下几种依赖范围:

  • compile:默认依赖范围。对于编译、测试和运行三种classpath都有效。 
  • test:只对于测试classpath有效
  • provided:只对编译和测试classpath有效,但在运行时无效。
  • runtime:对于测试和运行classpath有效,但在编译主代码时无效。
  • system:该依赖范围与三种classpath的关系和provided依赖范围完全一致。但是,使用system范围的依赖时,必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库获取的,而且往往与本机系统绑定,可能会造成不可移植,因此应该谨慎使用
  • import:该依赖范围不会对三种classpath产生实际影响。在继承和依赖管理时再介绍。

 


四、传递性依赖
     假设A依赖于B,B依赖于C,C就是A的传递性依赖。B是A的第一直接依赖,C是B的第二直接依赖。
     依赖范围不仅可控制依赖与三种classpath的关系,还会对传递性依赖产生影响。 第一直接依赖和第二直接依赖的范围会影响传递性依赖的范围。
当第二直接依赖的范围是compile时,传递性依赖的范围与第一直接依赖的范围一致;
当第二直接依赖的范围是test的时候,依赖不会传递;
当第二直接依赖的范围是provided时,只传递第一直接依赖范围也为provided的依赖,且传递性依赖的范围同样为provided;
当第二直接依赖的范围是runtime时,传递性依赖的范围与第一直接依赖的范围一致,但compile除外,此时传递性依赖的范围为runtime。

 


五、依赖调解
      Maven的依赖传递机器大大简化了依赖声明。大部分情况下,我们只需要关心项目的直接依赖,而不用考虑这些直接依赖会引入什么传递性依赖。但有时候,传递性依赖造成问题时,我们就需要清楚地知道传递性依赖是从哪条路径引入的。

例如,项目A的依赖关系为:A->B->C->X(1.0)、A->D->X(2.0)。X是A的传递性依赖,但是两条路径上的X版本不一致。
      Maven的依赖调解第一原则是:路径最近者优先,第二原则是:第一声明者优先。

 


六、可选依赖
      在声明依赖时可使用<optional>true<optional>标准,这表明是可选依赖,它们只会对当前项目产生影响,其他项目依赖于B时候,这两个依赖不会被传递。如果真要使用这个依赖,需要在项目中直接声明。
理想情况下,是不应该使用可选依赖的,使用可靠依赖的原因是某一个项目实现了多个特性,依据单一职责原则,更好的做法是他建多个Maven项目,用户根据需要选择使用哪个Maven项目。

 


七、最佳实践
1.排除依赖
      传递性依赖简化项目依赖的管理的同时,也可能会带来一些问题。例如,第当前项目有一个第三方依赖,而这个第三方依赖由于某些原因依赖了另一个类库的SNAPSHOT版本,而SNAPSHOT是不稳定的版本。这里就需要排除掉该SHAPSHOT版本,并在当前项目中声明该类库的某个正式版本。还有一些情况,比如Sun JTA API等由于版权因素,我们希望使用其他版本实现来代替。这时就可以使用:

 

<dependency>
	<exclusions>
		<exclusion>
			<groupId></groupId>
			<artifactId></artifactId>
		</exclusion>
	</exclusions>
</dependency>

 

     排除依赖不需要指定版本号

 

2.归类依赖
      在我们一些框架如Spring FrameWork时,会有很多依赖,它们的版本号是相同的。这时我们可以声明一个变量,然后在其他地方使用这个变量 。
声明变量如下:

<project>
<properties>
	<property>
		<springframework.version>2.5.6</springframework.version>
	</property>
</properties>
</project>

 

      使用方法如下:

<version>${springframework.version}</version>

 

 3.依赖分析优化
mvn dependency:list 查看解析后的最终依赖
mvn dependency:tree 查看解析后的依赖树
mvn dependency:analyze 帮助分析当前项目的依赖 
该命令的结果主要有两个部分:
首先是Used undeclared dependencies,指项目中使用到的,但是没有显式声明的依赖。
其次是Unused declared dependencies,指项目中未使用的显式依赖。

你可能感兴趣的:(spring,maven,C++,c,项目管理)