Maven3实战笔记05仓库依赖解析与插件解析

1.  Maven仓库依赖解析机制

本节复习前文背景是：http://suhuanzheng7784877.iteye.com/blog/1069252

当本地仓库没有依赖组件的时候，Maven会从远程的中心仓库或者私服下载依赖包，当依赖的版本是快照版本的时候，则自动先找到快照的最新版本。

1.1：当依赖范围是system的时候，Maven直接从本地库解析

1.2：根据咱们之前提到的Maven坐标解析路径后，开始查找工作，如果根据坐标发现了该组件，那么认为此次解析依赖成功

 

2.1：当本地仓库不存在相应组件的情况下，如果在pom.xml写着以来的版本是显示的发布版本，例如

		<dependency>
			<groupId>javax.mail</groupId>
			<artifactId>mail</artifactId>
			<version>1.4.1</version>
		</dependency>

  就是要javax.mail.jar.1.4.1版本，遍历远程仓库，如果在远程仓库发现了精确版本，下载。

2.2.1：如果在pom.xml文件中依赖写着的版本是基于更新策略（RELEASE或者LATEST）读取远程仓库元数据，将远程元数据的版本与本地仓库元数据仓库对应合并后，计算出版本真实值，然后基于这个真实的值检查本地和远程仓库。重复1.1和1.2步骤。

2.2.2：如果pom文件中依赖的版本是快照版本SNAPSHOP版本，则读取远程仓库的元数据，将其与本地仓库元数据进行对比，合并，得到一个快照版本值，之后看哪个比较新，从相应的库下载（一般都是远程仓库比本地的新，基本不可能本地的比远程的仓库版本还新吧，除非是该组件的原作者）

2.2.3：如果最后解析出来的版本是时间戳，会将其替换成快照格式。

从而可以看出，当依赖版本很“暧昧”的时候—— RELEASE 、 LATEST 、 SNAPSHOP ， Maven 需要将本地仓库和远程仓库进行对比，本地库与远程库要进行合并、更新。与此有关的配置是 releases 、 snapshots ，只有开启了相关配置，才能访问仓库的发布版本信息。

	<repositories>
		<repository>
			<id>jboss</id>
			<url>http://repository.jboss.com/maven2/</url>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
			<layout>default</layout>
		</repository>
	</repositories>

 RELEASE：代表最新发布版本（发布的意思就是较为稳定，经过测试）

LATEST：代表最新版本（包含快照版本）

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>org.icefaces</groupId>
  <artifactId>icefaces-comps</artifactId>
  <version>1.6.1</version>
  <versioning>
    <versions>
      <version>1.6.1</version>
      <version>1.6.2</version>
      <version>1.7.0</version>
      <version>1.7.1</version>
      <version>1.7.2</version>
      <version>1.8.0</version>
    </versions>
    <lastUpdated>20110602022501</lastUpdated>
  </versioning>
</metadata>

 

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>org.eclipse.persistence</groupId>
  <artifactId>eclipselink</artifactId>
  <version>1.0.2</version>
  <versioning>
    <versions>
      <version>1.0.2</version>
    </versions>
    <lastUpdated>20110602022437</lastUpdated>
  </versioning>
</metadata>

 需要注意的是，这种暧昧的版本在Maven中不太推荐，有可能今天构建成功了，明天第三方组织发布了一个快照版本，接口全变了，那就构建失败了。所以别搞暧昧，需要什么版本，大大方方的提出来即可。

2.  Maven插件解析机制

本节复习前文背景是：http://suhuanzheng7784877.iteye.com/blog/1069257

我们使用Maven插件的目标的时候都是利用他的前缀（简写），一旦执行命令出问题了，比较难定位具体是哪个插件运行出错的。在此咱们一起来看看它的插件插件机制。为何将仓库的依赖解析和插件解析放在一起呢，因为他们确实有相似的地方。插件的组件也是基于坐标存在于Maven库中，需要的时候，从本地仓库需要相关插件，不存在，从远程仓库去找，找到后下载到本地。当然了区别于依赖的是插件的远程库必须显示的在pom文件中配置，不配置，不会去远程下载。

	<pluginRepositories>
		<pluginRepository>
			<id>central</id>
			<name>Maven plugin</name>
			<url>htpp://repo1.maven.org/maven2</url>
			<layout>default</layout>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
			<releases>
				<enabled>false</enabled>
			</releases>
		</pluginRepository>
	</pluginRepositories>

 这个和依赖库的配置意思差不多打开快照版本插件，如果自己写了Maven插件，可以参考上面的配置。使用插件时，默认的groupId的值是org.apache.maven.plugins，是官方apache标准插件。

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-shade-plugin</artifactId>
				<executions>
					<execution>
						<phase>package</phase>
						<goals>
							<goal>shade</goal>
						</goals>
						<configuration>
							<transformers
								implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
								<mainClass>com.liuyan.maven.helloword.HelloWorld</mainClass>

							</transformers>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

 <groupId>org.apache.maven.plugins</groupId>其实可以省略。

使用插件的版本解析和仓库依赖组件的解析一样，先从本地解析，寻找。没有了从配置仓库查找。同样建议别使用“暧昧”版本插件。

至于插件的前缀解析机制，可以参看插件元数据

Windows7平台：C:\Users\用户名\.m2\repository\org\apache\maven\plugins下面的maven-metadata-central.xml文件描述了大多数常用的插件信息、以及前缀简写信息。使用——简写插件：目标后Maven会根据简写找到具体的插件全名，之后根据插件的当前元数据groupId，之后在找到版本号信息，最后就得到了完整的该插件的完整坐标。之后按照坐标去找具体实现、下载、使用之。

3.  总结

这次补充了仓库依赖和插件的解析机制，让我们更了解一些Maven的内核机制。