- 浏览: 237809 次
- 性别:
文章分类
最新评论
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写着以来的版本是显示的发布版本,例如
就是要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,只有开启了相关配置,才能访问仓库的发布版本信息。
RELEASE:代表最新发布版本(发布的意思就是较为稳定,经过测试)
LATEST:代表最新版本(包含快照版本)
需要注意的是,这种暧昧的版本在Maven中不太推荐,有可能今天构建成功了,明天第三方组织发布了一个快照版本,接口全变了,那就构建失败了。所以别搞暧昧,需要什么版本,大大方方的提出来即可。
2. Maven插件解析机制
本节复习前文背景是:http://suhuanzheng7784877.iteye.com/blog/1069257
我们使用Maven插件的目标的时候都是利用他的前缀(简写),一旦执行命令出问题了,比较难定位具体是哪个插件运行出错的。在此咱们一起来看看它的插件插件机制。为何将仓库的依赖解析和插件解析放在一起呢,因为他们确实有相似的地方。插件的组件也是基于坐标存在于Maven库中,需要的时候,从本地仓库需要相关插件,不存在,从远程仓库去找,找到后下载到本地。当然了区别于依赖的是插件的远程库必须显示的在pom文件中配置,不配置,不会去远程下载。
这个和依赖库的配置意思差不多打开快照版本插件,如果自己写了Maven插件,可以参考上面的配置。使用插件时,默认的groupId的值是org.apache.maven.plugins,是官方apache标准插件。
<groupId>org.apache.maven.plugins</groupId>其实可以省略。
使用插件的版本解析和仓库依赖组件的解析一样,先从本地解析,寻找。没有了从配置仓库查找。同样建议别使用“暧昧”版本插件。
至于插件的前缀解析机制,可以参看插件元数据
Windows7平台:C:\Users\用户名\.m2\repository\org\apache\maven\plugins下面的maven-metadata-central.xml文件描述了大多数常用的插件信息、以及前缀简写信息。使用——简写插件:目标后Maven会根据简写找到具体的插件全名,之后根据插件的当前元数据groupId,之后在找到版本号信息,最后就得到了完整的该插件的完整坐标。之后按照坐标去找具体实现、下载、使用之。
3. 总结
这次补充了仓库依赖和插件的解析机制,让我们更了解一些Maven的内核机制。
大家可能注意到了,在基于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
2012-12-17 19:03 1169maven常见问题问答 http://www.iteye.co ... -
maven文章汇总
2012-01-22 14:14 807http://blog.csdn.net/symgdwyh/a ... -
《Maven 实战》读书笔记(八) 反应堆
2012-01-07 14:46 9951. 反应堆 反应堆这个名字听上去挺专业,其实就是多个模块 ... -
《Maven 实战》读书笔记(七) 聚合
2012-01-07 14:43 9601. 继承 之前我们学习Maven的聚合机制遗留个问题,就 ... -
《Maven 实战》读书笔记(六) 聚合
2012-01-07 14:40 9211. Maven聚合的概念 聚合概念是由来已久, ... -
《Maven 实战》读书笔记(五) Maven的生命周期 和插件
2012-01-07 14:10 15161. Maven的生命周期 Maven的生命周期其实是指它 ... -
《Maven 实战》读书笔记(五)
2012-01-07 14:00 01. 仓库的概念 大家可能注意到了,在基于Maven管理的 ... -
ddssss
2012-01-03 19:08 6<plugin> <groupId& ... -
《Maven 实战》读书笔记(三) 坐标和依赖
2012-01-03 19:06 1006第五章:坐标和依赖 1.JAVA构件,MAVEN就必须将它们 ... -
《Maven实战》读书笔记(二) Maven使用入门
2012-01-03 19:04 1023第三章:Maven使用入门 ... -
《Maven实战》读书笔记(一) Maven简介
2012-01-03 18:57 1125第一章:Maven简介 1.Mave ...
相关推荐
Maven3实战笔记(整合)
Maven3实战笔记 Maven3实战笔记 Maven3实战笔记 Maven3实战笔记
Maven3实战笔记——03Maven仓库。
Maven实战的笔记,通读了Maven实战这本书之后,结合自己的经验,提取了其中大部分使用的操作以及使用经验。采用md编写文档,使用markdown编辑器查看效果更佳
Maven3实战笔记05——仓库依赖解析与插件解析。
Maven3实战笔记06——聚合的介绍。
maven学习笔记maven学习笔记maven学习笔记
Maven3实战笔记08——Maven反应堆。
Maven3实战笔记(全) 从安装配置,到仓库依赖,到集成测试,到插件管理,到构建web 作者风趣幽默的介绍了maven3的使用 强烈推荐
Maven3实战笔记10——使用Maven进行测试。
Maven3实战笔记07——继承的介绍。
Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清
Maven3实战笔记04——Maven的生命周期和插件。
Maven实战Maven实战Maven的安装、配置及使用入门
Maven3实战笔记
Maven的安装: (首先保证JDK版本在1.6以上) 1: 通过配置MAVEN_HOME 和 %% %MAVEN_HOME%\bin 然后进行mvn -version 测试 掌握 -Xms 与 -Xmx的相关配置 2: Maven目录分析: 2.1: bin: 含有mvn运行的脚本 2.2...
Maven3实战笔记,介绍maven构建项目的步骤以及相关内容
maven 实战 所有源代码
Maven实战.pdf 不可多得的权威maven中文书籍
Maven实战 好书 学习参考.pdf