标签:maven maven依赖管理 maven插件管理 maven继承聚合 maven约定优于配置
并不是父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>
插件管理与依赖管理原理一样、不同的是定义的元素标签不一样、插件管理标签是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>
注意的东西与依赖管理类似、只是换成了插件管理。
标准的重要性已经不用过多强调、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路径下。
标签:maven maven依赖管理 maven插件管理 maven继承聚合 maven约定优于配置
原文地址:http://blog.csdn.net/crave_shy/article/details/40923721