maven实战笔记-4

                                             第五章    坐标和依赖

    5.2  坐标详解
     <groupId>com.wangsy</groupId>
     <artifactId>testMVN</artifactId>
     <version>1.0.0</version>
     <packaging>jar</packaging>
 

    各个坐标元素：

• groupId：定义当前Maven项目隶属的实际项目。首先，Maven项目和实际项目不一定是一对一的关系。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目。最后，groupId的表示方式与Java包含的表示方式类似，通常与域名反向一一对应。
• artifactId：该元素定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。
• version:该元素定义Maven项目当前所处的版本。
• ackaging：该元素定义Maven项目的打包方式。首先，打包方式通常与所生成构件的文件扩展名对应。其次，打包方式会影响到构建的生命周期。
• classifier：该元素用来帮助定义构建输出的一些附属构件。、
  上述5个元素中，groupId、artifactId、version是必须定义的，packaging是可选的（默认为jar），而classifier是不能直接定义的。

    5.5  依赖范围

•     compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试和运行的时候都需要使用该依赖。
• test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
• provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
• runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。 
• system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量，如：
  <dependency>
      <groupId>javax.sql</groupId>
      <artifactId>jdbc-stdext</artifactId>
      <version>2.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/lib/rt.jar</systemPath>
  </dependency>
• import（Maven2.0.9及以上）：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。
   

依赖范围与classpath的关系

 

依赖范围（Scope）	对于编译 classpath有效	对于测试classpath有效	对于运行时 有效	例子
compile	Y	Y	Y	spring-core
test	—	Y	—	JUnit
provided	Y	Y	—	servlet-api
runtime	—	Y	Y	JDBC驱动实现
system	Y	Y	—	本地的，Maven仓库之外的类文件

 

    5.6  传递性依赖
    5.6.1  何为传递性依赖

    account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-mail的compile范围依赖，commons-logging是account-mail的一个传递性依赖。如下图所示：

    5.6.2  传递性依赖和依赖范围

	compile	test	provided	runtime
compile	compile	—	—	runtime
test	test	—	—	test
provided	provided	—	provided	provided
runtime	runtime	—	—	runtime

 

    5.7  依赖调解
    例如，项目A有这样的依赖关系：A->B->C->X(1.0)、A->D->X(2.0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。Maven依赖调解的第一原则是：路径最近者优先。该例中X(1.0)的路径长度为3，而X(2.0)的路径长度为2，因此X(2.0)会被解析使用。
依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A->B->Y(1.0)、A->C->Y(2.0)，Y(1.0)和Y(2.0)的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在Maven2.0.8及之前的版本中，这是不确定的。但是从Maven2.0.9开始，为了尽可能避免构不确定性，Maven定义了依赖调解的第二原则；第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。该例中，如果B的依赖声明在C之前，那么Y(1.0)就会被解析使用。

    5.8  可选依赖

    

 

    5.9  最佳实践
    5.9.1  排除依赖
    排除传递性依赖
    <project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.wangsy.mvn</groupId>
        <artifactId>project-a</artifactId>
        <version>1.0.0</version>
        <dependencies>
            <dependency>
                <groupId>com.wangsy.mvn</groupId>
                <artifactId> project-b</artifactId>
                <version>1.0.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.wangsy.mvn</groupId>
                        <artifactId> project-c</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <dependency>
                <groupId>com.wangsy.mvn</groupId>
                <artifactId> project-c</artifactId>
                <version>1.1.0</version>
            </dependency>
        <dependencies>
    </project>

    上述代码中，项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显式地声明对于项目C1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusion的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。

    5.9.2  归类依赖
    项目中有很多关于Spring Framework的依赖，它们分别是org.springframework：spring-core:2.5.6、org.springframework：spring-beans: 2.5.6、org.springframework：spring-context:2.5.6和org.springframework:spring-context-support:2.5.6，它们是来自同一项目的不同模块。因此，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。
    使用常量不仅让代码变得更加简洁，更重要的是可以避免重复，在需要更改的时候，只需要修改一处，降低了错误发生的概率。
    <project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.wangsy.account</groupId>
        <artifactId>account-email</artifactId>
        <name>Account Email</name>
        <version>1.0.0-SNAPSHOT</version>
        
        <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>
    </project>

    5.9.3  优化依赖
    查看当前项目的已解析依赖：
    mvn dependency:list
    
    查看当前项目的依赖树：
    mvn dependency:tree

    分析依赖树：
    mvn dependency:analyze
    
 

 

本文出自 “代码演绎人生” 博客，请务必保留此出处http://jawsy.blog.51cto.com/752812/544640