Maven之——依赖与插件管理

1、    依赖管理

并不是父POM中配置的所有依赖在不同的子类中都能用到、或者用到了但是不是统一版本、为解决这个、在父POM标签中定义依赖信息、在子POM中加入依赖的引入。具体细节如下：在父POM中配置项目中使用到的依赖、但是不再是dependency标签中配置、因为此标签可以自动被继承、使用dependencyManagement标签、此标签中定义的dependency不会被子POM自动引入、必须在子类中使用dependency声明。可能有些时候会觉得直接在子POM中引用依赖不就行了？一个是统一管理、另一个是简化配置后面有提到。依赖管理两部实现：

a）在父POM中配置需要引入的依赖管理——scattered-items中的pom.xml：

    <properties>
        <junit.version>4.1</junit.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>${junit.version}</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

上面使用了properties标签来定义全局变量、跟Java中定义变量意义项目、提取重复值。

b）在子POM中配置依赖——items-thkinjava中的pom.xml：

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </dependency>
    </dependencies>

子POM中关于junit的依赖的引入只需配置groupId和artifactId就可以了、版本和scope都不用指定。

注意：关键的地方是在父POM中的dependencyManagement标签中配置的依赖是不会主动引入到子项目中的、也就是说虽然在父POM中的dependencyManagement定义了junit的依赖、假如子类中没有关于junit的<dependency>、那么子类就没有junit依赖的引入、并且假如子项目不想使用4.1版本的junit、还可以指定自己想要使用的junit版本、这样就完全覆盖了父POM中关于junit的定义、也就是说父POM中的junit定义与他无关。这样的灵活性已经够满足我们日常需求了。

建议依赖都放在父POM中的dependencyManagement、一个是减少配置、二个是方便管理、比如版本冲突就是很常见的问题。通过dependencyManagement+变量的方式统一管理、更安全高效。

依赖范围有一种是import、是只有在dependencyManagement元素下才有效果的、使用该范围的依赖通常指向一个POM、作用是将目标POM中的dependencyManagement配置导入并合并到当前POM的dependencyManagement元素中。例如想在另外一个模块中使用上面配置的dependencyManagement配置、除了复制继承之外还可以使用import范围依赖将这已配置导入：

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.andy.items</groupId>
                <artifactId>scattered-items</artifactId>
                <type>pom</type>
                <version>1.0-SNAPSHOT</version>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>othergi</groupId>
                <artifactId>otherai</artifactId>
                <version>${other.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

3、    插件管理

插件管理与依赖管理原理一样、不同的是定义的元素标签不一样、插件管理标签是build标签的子标签pluginManagement、在父POM中定义、子POM引用。如前面有个生成源码包的插件、使用插件管理的配置过程如下：

a）父POM——scattered-items中的pom.xml：

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-source-plugin</artifactId>
                    <version>${sources.plugin.verion}</version>
                    <executions>
                        <execution>
                            <id>attach-sources</id>
                            <phase>verify</phase>
                            <goals>
                                <goal>jar-no-fork</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.1</version>
                    <configuration>
                        <source>1.7</source>
                        <target>1.7</target>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

b）子POM——items-thkinjava中的pom.xml:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

注意的东西与依赖管理类似、只是换成了插件管理。

4、    约定优于配置

标准的重要性已经不用过多强调、ConventionOver Configuration是maven最核心的设计理念之一。

任何一个maven项目都隐式的继承了超级POM、有点类似与Java所有的类都继承Object类、因此、大量超级POM的配置都会被所有maven项目继承、这些配置也就成为了maven所提倡的约定。

超级POM位置：$M2_HOME/lib/maven-model-builder-x.x.x.jar中的org/apache/maven/model/pom-4.0.0.xml路径下。