Maven中的元素Exclusions、modules、parent、properties以及import

Dependencies：是可选依赖（Optional Dependencies）
Exclusions：是依赖排除（Dependency Exclusions）
2、Dependencies
（1）当一个项目A依赖另一个项目B时，项目A可能很少一部分功能用到了项目B，此时就可以在A中配置对B的可选依赖。举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。
（2）配置可选依赖的原因：
1）节约磁盘、内存等空间；
2）避免license许可问题；
3）避免类路径问题，等等。
（3）示例：

<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
</dependencies>
</project>

　　假设以上配置是项目A的配置，即：Project-A –> Project-B。在编译项目A时，是可以正常通过的。如果有一个新的项目X依赖A，即：Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在pom.xml中重新配置对项目B的依赖。假设A->B, B->x（可选）, B->y（可选）。这里由于x，y是可选依赖，依赖不会传递，x，y将不会对a有任何影响

3、Exclusions
（1）当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。
（2）示例（假设配置的是A的pom.xml，依赖关系为：A –> B; B –> C）：

<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>

4、maven的依赖调解有两大原则：路径最近者优先；第一声明者优先。
5、maven的归类依赖

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

定义此属性值后，maven会将pom中的所有的${springframework.version}替换成实际值2.5.6

modules

　　从字面意思来说，module就是模块，而pom.xml中的modules也正是这个意思，用来管理同个项目中的各个模块；如果maven用的比较简单，或者说项目的模块在pom.xml没进行划分，那么此元素是用不到的；不过一般大一点的项目是要用到的。

　　1.需求场景

　　　　如果我们的项目分成了好几个模块，那么我们构建的时候是不是有几个模块就需要构建几次了（到每个模块的目录下执行mvn命令）？当然，你逐个构建没问题，但是非要这么麻烦的一个一个的构建吗，那么简单的做法就是使用聚合，一次构建全部模块。

　　2.具体实现

　　　　a.既然使用聚合，那么就需要一个聚合的载体，先创建一个普通的maven项目account-aggregator,如下图：

　　　　因为是个聚合体，仅仅负责聚合其他模块，那么就只需要上述目录，该删除的就删了；注意的是pom文件的书写（红色标明的）：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.youzhibing.account</groupId>
  <artifactId>account-aggregator</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>

  <name>Account Aggrregator</name>
  <url>http://maven.apache.org</url>
  
  <modules>
　　　 <!-- 模块都写在此处 -->
      <module>account-register</module>
      <module>account-persist</module>
  </modules>

</project>

　　　　b.创建子模account-register、account-persist:右击account-aggregator，new --> other --> Maven，选择Maven Module，创建moven模块。

　　　　c.创建完成后，项目结构如下，那么此时account-aggregator可以收缩起来了，我们操作具体子模块就好了。

　　　　d.注意点，当我们打开包结构的子模块的pom文件时，发现离预期的多了一些内容，我们坐下处理就好了。

　　　　e.那么编码完了之后，我们只需要构建account-aggregator就好了，所有的子模块都会构建。

parent

　　继承，和java中的继承相当，作用就是复用

　　1.需求场景

　　　　若每个子模块都都用的了spring，那么我们是不是每个子模块都需要单独配置spring依赖了?,这么做是可以的，但是我们有更优的做法，那就是继承，用parent来实现。

　　2.具体实现

　　　　a.配置父pom.xml

　　　　　　我就用聚合pom来做父pom,配置子模块的公共依赖。

　　　　　　父(account-aggregator)pom.xml :

View Code

　　　　b.account-register的pom.xml :

View Code

　　　　c.account-persist的pom.xml :

View Code

　　　　d.依赖的jar包全部ok，需要做的则是在各个模块中进行代码开发了！

　　3.依赖管理

　　　　继承可以消除重复，那是不是就没有问题了？答案是存在问题，假设将来需要添加一个新的子模块account-util，该模块只是提供一些简单的帮助工具，不需要依赖spring、junit，那么继承后就依赖上了，有没有什么办法了？有，maven已经替我们想到了，那就是dependencyManagement元素，既能让子模块继承到父模块的依赖配置，又能保证子模块依赖使用的灵活性。在dependencyManagement元素下得依赖声明不会引入实际的依赖，不过它能够约束dependencies下的依赖使用。

　　　　在父pom.xml中配置dependencyManagement元素

View Code

　　　　account-persist的pom.xml(account-register也一样) ：

View Code

　　　　使用这种依赖管理机制似乎不能减少太多的POM配置，就少了version(junit还少了个scope)，感觉没啥作用呀；其实作用还是挺大的，父POM使用dependencyManagement能够统一项目范围中依赖的版本，当依赖版本在父POM中声明后，子模块在使用依赖的时候就无须声明版本，也就不会发生多个子模块使用版本不一致的情况，帮助降低依赖冲突的几率。如果子模块不声明依赖的使用，即使该依赖在父POM中的dependencyManagement中声明了，也不会产生任何效果。

import

　　import只在dependencyManagement元素下才有效果，作用是将目标POM中的dependencyManagement配置导入并合并到当前POM的dependencyManagement元素中，如下就是讲account-aggregator中的dependencyManagement配置导入并合并到当前POM中。

<dependencyManagement>
      <dependencies>
        <dependency>
            <groupId>com.youzhibing.account</groupId>
              <artifactId>account-aggregator</artifactId>
              <version>1.0.0-SNAPSHOT</version>
            <type>pom</type>
              <scope>import</scope>
        </dependency>
      </dependencies>
  </dependencyManagement>

properties(Maven属性)

　　通过<properties>元素用户可以自定义一个或多个Maven属性，然后在POM的其他地方使用${属性名}的方式引用该属性，这种做法的最大意义在于消除重复和统一管理。

　　Maven总共有6类属性，内置属性、POM属性、自定义属性、Settings属性、java系统属性和环境变量属性；

　　1.内置属性

　　　　两个常用内置属性 ${basedir} 表示项目跟目录，即包含pom.xml文件的目录；${version} 表示项目版本

　　2.POM属性

　　　　用户可以使用该类属性引用POM文件中对应元素的值。如${project.artifactId}就对应了<project> <artifactId>元素的值，常用的POM属性包括：

　　　　${project.build.sourceDirectory}:项目的主源码目录，默认为src/main/java/

　　　　${project.build.testSourceDirectory}:项目的测试源码目录，默认为src/test/java/

　　　　${project.build.directory} ：项目构建输出目录，默认为target/

　　　　${project.outputDirectory} : 项目主代码编译输出目录，默认为target/classes/

　　　　${project.testOutputDirectory}：项目测试主代码输出目录，默认为target/testclasses/

　　　　${project.groupId}：项目的groupId

　　　　${project.artifactId}：项目的artifactId

　　　　${project.version}：项目的version,与${version} 等价

　　　　${project.build.finalName}：项目打包输出文件的名称，默认为${project.artifactId}-${project.version}

　　3.自定义属性

　　　　如下account-aggregator的pom.xml，那么继承了此pom.xml的子模块也可以用此自定义属性

View Code

　　4.Settings属性

　　　　与POM属性同理，用户使用以settings. 开头的属性引用settings.xml文件中的XML元素的值。

　　5.Java系统属性

　　　　所有java系统属性都可以用Maven属性引用，如${user.home}指向了用户目录。

　　6.环境变量属性

　　　　所有环境变量属性都可以使用以env. 开头的Maven属性引用，如${env.JAVA_HOME}指代了JAVA_HOME环境变量的的值。

聚合与继承的关系

　　1.聚合主要是为了方便快速构建项目，继承主要是为了消除重复配置；

　　2.对于聚合模块而言，它知道有哪些被聚合的模块，但那些被聚合的模块不知道这个聚合模块的存在；对于继承的父pom而言，它不知道有哪些子模块继承它，但那些子模块都必须知道自己的父POM是什么；

　　3.聚合POM与继承中的父POM的packaging都必须是pom；同时，聚合模块与继承中的父模块除了POM外，都没有实际的内容

结束语

　　maven越来越流行，这方面的资料也是越来越多，《Maven实战》给我的感觉就相当不错，本博客的内容大多取自其中；网上资料也越来越多，就博客园中就有不少；

Maven中的元素Exclusions、modules、parent、properties以及import

猜你喜欢