1.坐标详解

Maven坐标为各种构件引入了秩序,任何一个构件都必须明确定义自己的坐标,而一组Maven坐标是通过一些元素定义的,它们是groupId、artifactId、version、packaging、classifier。

groupId： 定义当前Maven项目隶属的实际项目。

artifactId： 该元素定义实际项目中的一个Maven项目（模块）,推荐的做法是使用实际项目名称作为artifactId的前缀。

version： 该元素定义Maven项目当前所处的版本

packaging： 该元素定义Maven项目的打包方式,当不定义packaging的时候,Maven会使用默认值jar。

classifier： 该元素用来帮助定义构建输出的一些附属构件。附属构件与主构件对应,如上例中的主构件是nexus-indexer-2.0.0.jar,该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些附属构件,其包含了Java文档和源代码。这时候,javadoc和sources就是这两个附属构件的classifier。这样,附属构件也就拥有了自己唯一的坐标。

上述5个元素中,groupId、artifactId、version是必须定义的,packaging是可选的（默认为jar）,而classifier是不能直接定义的。

同时,项目构件的文件名是与坐标相对应的,一般的规则为artifactId-version［-classifier］.packaging,［-classifier］表示可选。

这里还要强调的一点是,packaging并非一定与构件扩展名对应,比如packaging为maven-plugin的构件扩展名为jar。

2.依赖配置格式

根元素project下的dependencies可以包含一个或者多个dependency元素,以声明一个或者多个项目依赖。每个依赖可以包含的

元素有：

groupId、artifactId和version： 依赖的基本坐标,对于任何一个依赖来说,基本坐标是最重要的,Maven根据坐标才能找到需要的依赖。

type： 依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认值为jar。

scope： 依赖的范围,依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系,Maven有以下几种依赖范围：

compile： 编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。

test： 测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此类依赖。

provided： 已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要Maven重复地引入一遍。

runtime： 运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

system： 系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使用。

import（Maven 2.0.9及以上）： 导入依赖范围。该依赖范围不会对三种classpath产生实际的影响,本书将在8.3.3节介绍Maven依赖和dependencyManagement的时候详细介绍此依赖范围。

大部分依赖声明只包含基本坐标,然而在一些特殊情况下,其他元素至关重要。

3.传递性依赖

有了传递性依赖机制,在使用Spring Framework的时候就不用去考虑它依赖了什么,也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目中。

4.传递性依赖和依赖范围

当第二直接依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致；当第二直接依赖的范围是test的时候,依赖不会得以传递；当第二直接依赖的范围是provided的时候,只传递第一直接依赖范围也为provided的依赖,且传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候,传递性依赖的范围与第一直接依赖的范围一致,但compile例外,此时传递性依赖的范围为runtime。

5.依赖调解

例如,项目A有这样的依赖关系：A->B->C->X（1.0）、A->D->X（2.0）,X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的,因为那会造成依赖重复,因此必须选择一个。Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。该例中X（1.0）的路径长度为3,而X（2.0）的路径长度为2,因此X（2.0）会被解析使用。

Maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下,在POM中依赖声明的顺序决定了谁会被解析使用,顺序最靠前的那个依赖优胜。

6.可选依赖

<dependency>
<optional>true</optional>
</dependency>



<optional>元素表示可选依赖.

项目B实现了两个特性,其中的特性一依赖于X,特性二依赖于Y,而且这两个特性是互斥的,用户不可能同时使用两个特性。比如B是一个持久层隔离工具包,它支持多种数据库,包括MySQL、PostgreSQL等,在构建这个工具包的时候,需要这两种数据库的驱动程序,但在使用这个工具包的时候,只会依赖一种数据库。

7.排除依赖

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



项目A依赖于项目B,但是由于一些原因,不想引入传递性依赖C,而是自己显式地声明对于项目C 1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖,exclusions可以包含一个或者多个exclusion子元素,因此可以排除一个或者多个传递性依赖。需要注意的是,声明exclusion的时候只需要groupId和artifactId,而不需要version元素,这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说,Maven解析后的依赖中,不可能出现groupId和artifactId相同,但是version不同的两个依赖

8.归类依赖

<project>
....
<properties>
<变量名>值</变量名>
</properties>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version>${变量名}</version>
</dependency>
</dependencies>
</project>



这里简单用到了Maven属性,首先使用properties元素定义Maven属性,使用美元符号和大括弧环绕的方式引用Maven属性。然后,将所有依赖的版本值用这一属性引用表示。这和在Java中用常量PI替换3.14是同样的道理,不同的只是语法。

9.优化依赖

运行命令查看当前项目的已解析依赖：mvn dependency:list,在此基础上,还能进一步了解已解析依赖的信息。将直接在当前项目POM声明的依赖定义为顶层依赖,而这些顶层依赖的依赖则定义为第二层依赖,以此类推,有第三、第四层依赖。当这些依赖经Maven解析后,就会构成一个依赖树,通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以行如下命令查看当前项目的依赖树：mvn dependency:tree,在此基础上,还有dependency：analyze工具可以帮助分析当前项目的依赖。为了说明该工具的用途,先将spring-context这一依赖删除,然后构建项目,你会发现编译、测试和打包都不会有任何问题。通过分析依赖树,可以看到spring-context是spring-context-support的依赖,因此会得以传递到项目的classspath中。

前言
Maven中可以通过继承父模块pom，来实现pom.xml配置的继承和传递，便于各种Maven插件以及程序依赖的统一管理。通过将子类模块的公共配置，抽象聚合生成父类模块，能够避免pom.xml的重复配置。由于父类模块本身并不包含除了POM之外的项目文件，也就不需要src/main/java之类的文件夹了。每当需要对多个子模块进行相同的配置时，只需要在父类模块的pom中进行配置，而子类中声明使用此配置即可，当然子类pom中也可以自定义配置，并覆盖父类中的各项配置，和Java中类的继承类似。

可继承的POM元素
1) groupId：项目组ID，项目坐标的核心元素
2) version：项目版本，项目坐标的核心元素
3) description：项目的表述信息
4) organization：项目的组织信息
5) inception Year：项目的创始年份
6) url：项目的URL地址
7) developers：项目的开发者信息
8) contributors：项目的贡献者信息
9) distributionManagement：项目的部署管理
10) issueManagement：项目的缺陷和跟踪系统信息
11) ciManagement：项目的持续集成信息系统
12) scm：项目的版本控制系统信息
13) mailingLists：项目的邮件列表信息
14) properties：自定义的Maven属性
15) dependencies：项目的依赖属性
16) dependencyManagement：项目的依赖管理配置
17) repositories：项目的仓库配置
18) build：包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等
19) reporting：包括项目的报告输出目录配置、报告插件配置等

POM继承中的依赖管理和插件管理
Maven提供的dependencyManagement和pluginManagement元素用于帮助POM继承过程中的依赖管理和插件管理。在父类POM下，此两个元素中的声明的依赖或配置并不会引入实际的依赖或是造成实际的插件调用行为，不过它们能够约束子类POM中的依赖和插件配置的声明。只有当子类POM中配置了真正的dependency或plugin，并且其groupId和artifactId与父类POM中dependencyManagement和pluginManagement相对应时，才会进行实际的依赖引入或插件调用，当然子类中也能够进行自定义配置去覆盖父类，或是额外声明自己的配置

POM继承示例
1) 在父类POM中使用dependencyManagement和pluginManagement，声明子类POM中可能用到的依赖和插件
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.tomandersen</groupId>
    <artifactId>HadoopCustomModules</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <modules>
        <module>flume</module>
        <module>log-collector</module>
    </modules>

    <!--事先声明版本属性-->
    <properties>
        <slf4j.version>1.7.20</slf4j.version>
        <logback.version>1.0.7</logback.version>
    </properties>


    <!--在父类Maven中使用dependencyManagement声明依赖便于子类Module继承使用,也便于进行依赖版本控制-->
    <dependencyManagement>
        <dependencies>
            <!--阿里巴巴开源json解析框架-->
            <dependency>
                <groupId>com.alibaba</groupId>
                <artifactId>fastjson</artifactId>
                <version>1.2.51</version>
            </dependency>

            <!--日志生成框架-->
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-core</artifactId>
                <version>${logback.version}</version>
            </dependency>

            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-classic</artifactId>
                <version>${logback.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>


    <build>
        <!--在父类Maven中使用pluginManagement管理插件便于子类Module继承使用,也便于进行依赖版本控制-->
        <pluginManagement>
            <plugins>
                <!--配置Maven项目compiler插件-->
                <!--此工具不会打包依赖-->
                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>2.3.2</version>
                    <configuration>
                        <source>1.8</source>
                        <target>1.8</target>
                    </configuration>
                </plugin>

				<!--配置Maven项目assembly插件-->
            	<!--此工具会将全部依赖打包-->
                <plugin>
                    <artifactId>maven-assembly-plugin</artifactId>
                    <configuration>
                        <descriptorRefs>
                            <descriptorRef>jar-with-dependencies</descriptorRef>
                        </descriptorRefs>
                        <archive>
                            <manifest>
                                <!--子类Maven通过mainClass标签设置成主类的全类名FQCN-->
                                <!--<mainClass></mainClass>-->
                            </manifest>
                        </archive>
                    </configuration>
                    <executions>
                        <execution>
                            <id>make-assembly</id>
                            <phase>package</phase>
                            <goals>
                                <goal>single</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>

            </plugins>
        </pluginManagement>

    </build>

2) 在子类POM中声明父类POM，并配置实际使用的dependency和plugin，只需要通过声明groupId和artifactId就可以避免配置各种依赖和插件的详细配置，当然也可以自己覆盖父类配置信息
    <!--声明父类POM-->
    <parent>
        <artifactId>HadoopCustomModules</artifactId>
        <groupId>com.tomandersen</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <!--子类POM信息-->
    <groupId>com.tomandersen</groupId>
    <artifactId>log-collector</artifactId>

    <dependencies>
        <!--阿里巴巴开源json解析框架-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
        </dependency>

        <!--日志生成框架-->
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-core</artifactId>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!--自定义Maven项目编译器compiler插件相关配置-->
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
            </plugin>

            <!--自定义Maven项目汇编assembly插件相关配置-->
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <!--此处设置成主类的全名-->
                            <mainClass>com.tomandersen.appclient.AppMain</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>


更多详细内容可以查阅《Maven实战》

End~

IDEA多模块maven项目子模块无法引用父模块依赖
第一节 问题
第二节 解决方案

第一节 问题
当在IDEA创建一个maven项目后，并在该项目下新建一个moudle后，使得前一个maven项目作为父模块，配置信息如下：

MybatisDemo的pom.xml文件：

Mybatis-01的pom.xml文件：

但是新建java文件后，发现无法使用父模块中引用的依赖。
第二节 解决方案

这样就可以使用父模块的依赖了（反正我这样是可以的）。

 

1. 模块介绍

1.1模块如下

parent  为 父级，父级下只有一个pom文件主要，其他可忽略

B  为子模块，包含springboot 启动类

C 为公共模块，（不包含springboot 启动类）

D 为子模块，（不包含springboot 启动类）



1.2 依赖关系

绿色的代表，三个模块都交给parent 管理

红色的代表子模块之间依赖关系



2. pom配置

2.1 parent 配置

2.1.1 配置modules 以及自身



2.1.2 配置依赖 dependencyManagement



2.2 A 模块配置



2.3 B 模块配置



 

 

build 说明：项目打包编译失败：程序包xx不存在,报common下的类找不到异常，

  <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <classifier>exec</classifier>
                </configuration>
            </plugin>
        </plugins>
    </build>

 

2.4 C 模块配置