本文主要是介绍《Maven 实战》读书笔记（四） 仓库，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
0.1. 仓库的概念大家可能注意到了，在基于Maven管理的项目开发中，这个项目自身是不引进第三方jar包的，使用的时候通过pom.xml的依赖机制，从本地仓库或者远程仓库去获取第三方jar包。这个其实是打破了以往的开发习惯，一般我们是在开发项目的时候需要哪个jar包了，立刻google一下，找到相关网址，之后下载，放到我们项目的classpath中。现在是不必强制引用jar，只要通过pom.xml配置，到一定的时刻，比如编译、测试、打包、部署，自然会将依赖的jar放进您预先的位置。Maven仓库是基于简单文件系统存储的，根据咱们之前提到的坐标，可以找到该组件在仓库的位置。
0.2. 仓库的分类
一般说Maven的仓库就是指2个类型，一个就是我们自己的PC机器本地仓库，另一个就是指远程的Maven中心仓库（天啊，如果某天Maven组织宣布不对中国开放中心仓库那是怎样的局面啊？我的妈呀，太刺激啦~）。当本地仓库没有您需要的jar包的时候，它会从远程核心中心仓库中下载，所以说美国人想制约咱们中国的软件发展是很容易的，现在搞得连仓库都云计算、云存储了，真要是中美打起仗来……。不过我们有私服，私服就是另一种特殊的远程仓库，为了节省Maven核心仓库的带宽和时间，很多企业都在公司的局域网内搭建了私有的仓库服务器，内部项目先从私服下载东东，没有的时候私服从外网中心仓库下载，内部开发的项目还能上传到私服上供其他项目组使用。
0.3. 本地仓库明细
本地仓库大家已经不陌生了，默认是在用户临时文件夹的~/.m2/repository下。
settings.xml中
1. Maven仓库依赖解析机制
当本地仓库没有依赖组件的时候，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的内核机制。
这篇关于《Maven 实战》读书笔记（四） 仓库的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
