晋江市住房建设局网站,浙江人工智能建站系统软件,区域教育联盟网站建设,右26cmMaven坐标和依赖是任何一个构件在Maven世界中的逻辑表示方式#xff1b;而构件的物理表示方式是文件#xff0c;Maven通过仓库来统一管理这些文件。
1、何为Maven仓库
在Maven世界中#xff0c;任何一个依赖、插件或者项目构建的输出#xff0c;都可以称为构件。例如而构件的物理表示方式是文件Maven通过仓库来统一管理这些文件。
1、何为Maven仓库
在Maven世界中任何一个依赖、插件或者项目构建的输出都可以称为构件。例如依赖log4j-1.2.15.jar是一个构件插件maven-compiler-plugin-2.0.2.jar是一个构件。任何一个构件都有一组坐标唯一标识。
在一台工作站上可能会有几十个Maven项目所有项目都使用maven-compiler-plugin这些项目中的大部分都用到了log4j有一小部分用到了Spring Framework还有另外一小部分用到了Struts2。在每个有需要的项目中都放置一份重复的log4j或者struts2显然不是最好的解决方案这样做不仅造成了磁盘空间的浪费而且也难于统一管理文件的复制等操作也会降低构建的速度。而实际情况是在不使用Maven的那些项目中我们往往就能发现命名为lib/的目录各个项目lib/目录下的内容存在大量的重复。
得益于坐标机制任何Maven项目使用任何一个构件的方式都是完全相同的。在此基础上Maven可以在某个位置统一存储所有Maven项目共享的构件这个统一的位置就是仓库。实际的Maven项目将不再各自存储其依赖文件它们只需要声明这些依赖的坐标在需要的时候例如编译项目的时候需要将依赖加入到classpath中Maven会自动根据坐标找到仓库中的构件并使用它们。
为了实现重用项目构建完毕后生成的构件也可以安装或者部署到仓库中供其他项目使用。
2、仓库的布局
任何一个构件都有其唯一的坐标根据这个坐标可以定义其在仓库中的唯一存储路径这便是Maven的仓库布局方式。例如log4j:log4j:1.2.15这一依赖其对应的仓库路径为log4j/log4j/1.2.15/log4j-1.2.15.jar细心的你可以观察到该路径与坐标的大致对应关系为groupId/artifactId/version/artifactId-version.packaging。下面看一段Maven的源码并结合具体的实例来理解Maven仓库的布局方式见代码清单如下
private static final char PATH_SEPARATOR/
private static final char GROUP_SEPARATOR.
private static final char ARTIFACT_SEPARATOR-
public String pathOfArtifact artifact{
ArtifactHandler artifactHandlerartifact.getArtifactHandler
StringBuilder pathnew StringBuilder128
path.appendformatAsDirectoryartifact.getGroupId.appendPATH_SEPA-RATOR
path.appendartifact.getArtifactId.appendPATH_SEPARATOR
path.appendartifact.getBaseVersion.appendPATH_SEPARATOR
path.appendartifact.getArtifactId.appendARTIFACT_SEPARATOR.appendartifact.getVersionifartifact.hasClassifier{path.appendARTIFACT_SEPARATOR.appendartifact.getClassifier}
ifartifactHandler.getExtensionnullartifactHandler.getExtension.length0{path.appendGROUP_SEPARATOR.appendartifactHandler.getExtension}return path.toString
}
private String formatAsDirectoryString directory{return directory.replaceGROUP_SEPARATOR,PATH_SEPARATOR
}该pathOf方法的目的是根据构件信息生成其在仓库中的路径。这里根据一个实际的例子来分析路径的生成考虑这样一个构件groupIdorg.testng、artifactIdtestng、version5.8、classifierjdk15、packagingjar其对应的路径按如下步骤生成 1基于构件的groupId准备路径formatAsDirectory将groupId中的句点分隔符转换成路径分隔符。该例中groupId org.testng就会被转换成org/testng之后再加一个路径分隔符斜杠那么org.testng就成为了org/testng/。
2基于构件的artifactId准备路径也就是在前面的基础上加上artifactId以及一个路径分隔符。该例中的artifactId为testng那么在这一步过后路径就成为了org/testng/testng/。
3使用版本信息。在前面的基础上加上version和路径分隔符。该例中版本是5.8那么路径就成为了org/testng/tesgng/5.8/。
4依次加上artifactId构件分隔符连字号以及version于是构建的路径就变成了org/testng/testng/5.8/testng-5.8。你可能会注意到这里使用了artifactId.getVersion而上一步用的是artifactId.getBaseVersionbaseVersion主要是为SNAPSHOT版本服务的例如version为1.0-SNAPSHOT的构件其baseVersion就是1.0。
5如果构件有classifier就加上构件分隔符和classifier。该例中构件的classifier是jdk15那么路径就变成org/testng/testng/5.8/testng-5.8-jdk5。
6检查构件的extension若extension存在则加上句点分隔符和extension。从代码中可以看到extension是从artifactHandler而非artifact获取artifactHandler是由项目的packaging决定的。因此可以说packaging决定了构件的扩展名该例的packaging是jar因此最终的路径为org/testng/testng/5.8/testng-5.8-jdk5.jar。
到这里应该感谢Maven开源社区正是由于Maven的所有源代码都是开放的我们才能仔细地深入到其内部工作的所有细节。
Maven仓库是基于简单文件系统存储的我们也理解了其存储方式因此当遇到一些与仓库相关的问题时可以很方便地查找相关文件方便定位问题。例如当Maven无法获得项目声明的依赖时可以查看该依赖对应的文件在仓库中是否存在如果不存在查看是否有其他版本可用等等。
3、仓库的分类
对于Maven来说仓库只分为两类本地仓库和远程仓库。当Maven根据坐标寻找构件的时候它首先会查看本地仓库如果本地仓库存在此构件则直接使用如果本地仓库不存在此构件或者需要查看是否有更新的构件版本Maven就会去远程仓库查找发现需要的构件之后下载到本地仓库再使用。如果本地仓库和远程仓库都没有需要的构件Maven就会报错。
在这个最基本分类的基础上还有必要介绍一些特殊的远程仓库。中央仓库是Maven核心自带的远程仓库它包含了绝大部分开源的构件。在默认配置下当本地仓库没有Maven需要的构件的时候它就会尝试从中央仓库下载。
除了中央仓库和私服还有很多其他公开的远程仓库常见的有Java.net Maven库http://download.java.net/maven/2/和JBoss Maven库http://repository.jboss.com/maven2/等。
Maven仓库的分类见下图
3.1、本地仓库
一般来说在Maven项目目录下没有诸如lib/这样用来存放依赖文件的目录。当Maven在执行编译或测试时如果需要使用依赖文件它总是基于坐标使用本地仓库的依赖文件。
默认情况下不管是在Windows还是Linux上每个用户在自己的用户目录下都有一个路径名为.m2/repository/的仓库目录。例如笔者的用户名是yyb我在Windows机器上的本地仓库地址为C:\Users\yyb.m2\repository\而我在Linux上的本地仓库地址为/home/yyb/.m2/repository/。注意在Linux系统中以点.开头的文件或目录默认是隐藏的可以使用ls-a命令显示隐藏文件或目录。
有时候因为某些原因例如C盘空间不够用户会想要自定义本地仓库目录地址。这时可以编辑文件/.m2/settings.xml设置localRepository元素的值为想要的仓库地址。例如
settings
localRepositoryD:\java\repository\/localRepository
/settings这样该用户的本地仓库地址就被设置成了D:\java\repository\。
需要注意的是默认情况下/.m2/settings.xml文件是不存在的用户需要从Maven安装目录复制$M2_HOME/conf/settings.xml文件再进行编辑。我始终推荐大家不要直接修改全局目录的settings.xml文件。
一个构件只有在本地仓库中之后才能由其他Maven项目使用那么构件如何进入到本地仓库中呢最常见的是依赖Maven从远程仓库下载到本地仓库中。还有一种常见的情况是将本地项目的构件安装到Maven仓库中。例如本地有两个项目A和B两者都无法从远程仓库获得而同时A又依赖于B为了能构建A,B就必须首先得以构建并安装到本地仓库中。
在某个项目中执行mvn clean install命令就能看到如下输出
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: D:git-juven maven-book code ch-5 account-email targetaccount-email-1.0.0-SNAPSHOT.jar
[INFO] [install:install {execution:default-install}][INFO] Installing D:git-juvenmaven-bookcodech-5 account-emailtargetaccount-email-1.0.0-SNAPSHOT.jar to D:javarepositorycomjuvenmvnbook account account-email1.0.0-SNAPSHOTaccount-email-1.0.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO] Install插件的install目标将项目的构建输出文件安装到本地仓库。在上述输出中构建输出文件是account-email-1.0.0-SNAPSHOT.jar本地仓库地址是D:\java\repository,Maven。
使用Install插件将该文件复制到本地仓库中具体的路径根据坐标计算获得。
3.2、远程仓库
安装好Maven后如果不执行任何Maven命令本地仓库目录是不存在的。当用户输入第一条Maven命令之后Maven才会创建本地仓库然后根据配置和需要从远程仓库下载构件至本地仓库。
这好比藏书。例如我想要读《红楼梦》会先检查自己的书房是否已经收藏了这本书如果发现没有这本书于是就跑去书店买一本回来放到书房里。可能有一天我又想读一本英文版的《程序员修炼之道》而书房里只有中文版于是又去书店找可发现书店没有好在还有网上书店于是从Amazon买了一本几天后我收到了这本书又放到了自己的书房。
本地仓库就好比书房我需要读书的时候先从书房找相应地Maven需要构件的时候先从本地仓库找。远程仓库就好比书店包括实体书店、网上书店等当我无法从自己的书房找到需要的书的时候就会从书店购买后放到书房里。当Maven无法从本地仓库找到需要的构件的时候就会从远程仓库下载构件至本地仓库。一般地对于每个人来说书房只有一个但外面的书店有很多类似地对于Maven来说每个用户只有一个本地仓库但可以配置访问很多远程仓库。
3.3、中央仓库
由于最原始的本地仓库是空的Maven必须知道至少一个可用的远程仓库才能在执行Maven命令的时候下载到需要的构件。中央仓库就是这样一个默认的远程仓库Maven的安装文件自带了中央仓库的配置。你可以使用解压工具打开jar文件$M2_HOME/lib/maven-model-builder-3.0.jar在Maven 2中jar文件路径类似于$M2_HOME/lib/maven-2.2.1-uber.jar然后访问路径org/apache/maven/model/pom-4.0.0.xmlmaven 2中为org/apache/maven/project/pom-4.0.0.xml可以看到
repositories
repository
idcentral/id
nameMaven Repository Switchboard/name
urlhttp://repo1.maven.org/maven2/url
layoutdefault/layout
snapshots
enabledfalse/enabled
/snapshots
/repository
/repositories包含这段配置的文件是所有Maven项目都会继承的超级POM。
这段配置使用id central对中央仓库进行唯一标识其名称为Maven Repository Switchboard它使用default仓库布局。对于Maven 1的仓库需要配置值为legacy的layout本书不会涉及Maven 1。最后需要注意的是snapshots元素其子元素enabled的值为false表示不从该中央仓库下载快照版本的构件。
中央仓库包含了这个世界上绝大多数流行的开源Java构件以及源码、作者信息、SCM、信息、许可证信息等每个月这里都会接受全世界Java程序员大概1亿次的访问它对全世界Java开发者的贡献由此可见一斑。由于中央仓库包含了超过2000个开源项目的构件因此一般来说一个简单Maven项目所需要的依赖构件都能从中央仓库下载到。这也解释了为什么Maven能做到“开箱即用”。
3.4、私服
私服是一种特殊的远程仓库它是架设在局域网内的仓库服务私服代理广域网上的远程仓库供局域网内的Maven用户使用。当Maven需要下载构件的时候它从私服请求如果私服上不存在该构件则从外部的远程仓库下载缓存在私服上之后再为Maven的下载请求提供服务。此外一些无法从外部仓库下载到的构件也能从本地上传到私服上供大家使用如下图所示 上图展示的是组织内部使用私服的情况。即使在一台直接连入Internet的个人机器上使用Maven也应该在本地建立私服。因为私服可以帮助你
节省自己的外网带宽。建立私服同样可以减少组织自己的开支大量的对于外部仓库的重复请求会消耗很大的带宽利用私服代理外部仓库之后对外的重复构件下载便得以消除即降低外网带宽的压力。加速Maven构建。不停地连接请求外部仓库是十分耗时的但是Maven的一些内部机制如快照更新检查要求Maven在执行构建的时候不停地检查远程仓库数据。因此当项目配置了很多外部远程仓库的时候构建的速度会被大大降低。使用私服可以很好地解决这一问题当Maven只需要检查局域网内私服的数据时构建的速度便能得到很大程度的提高。部署第三方构件。当某个构件无法从任何一个外部远程仓库获得怎么办这样的例子有很多如组织内部生成的私有构件肯定无法从外部仓库获得、Oracle的JDBC驱动由于版权因素不能发布到公共仓库中。建立私服之后便可以将这些构件部署到这个内部的仓库中供内部的Maven项目使用。提高稳定性增强控制。Maven构建高度依赖于远程仓库因此当Internet不稳定的时候Maven构建也会变得不稳定甚至无法构建。使用私服后即使暂时没有Internet连接由于私服中已经缓存了大量构件Maven也仍然可以正常运行。此外一些私服软件如Nexus还提供了很多额外的功能如权限管理、RELEASE/SNAPSHOT区分等管理员可以对仓库进行一些更高级的控制。降低中央仓库的负荷。运行并维护一个中央仓库不是一件容易的事情服务数百万的请求存储数T的数据需要相当大的财力。使用私服可以避免很多对中央仓库重复的下载想象一下一个有数百位开发人员的公司在不使用私服的情况下一个构件往往会被重复下载数百次建立私服之后这几百次下载就只会发生在内网范围内私服对于中央仓库只有一次下载。
4、远程仓库的配置
在很多情况下默认的中央仓库无法满足项目的需求可能项目需要的构件存在于另外一个远程仓库中如JBoss Maven仓库。这时可以在POM中配置该仓库见代码清单如下配置POM使用JBoss Maven仓库
project
……
repositories
repository
idjboss/id
nameJBoss Repository/name
urlhttp://repository.jboss.com/maven2//url
releases
enabledtrue/enabled
/releasessnapshots
enabledfalse/enabled
/snapshots
layoutdefault/layout
/repository
/repositories
……
/project在repositories元素下可以使用repository子元素声明一个或者多个远程仓库。该例中声明了一个id为jboss名称为JBoss Repository的仓库。任何一个仓库声明的id必须是唯一的尤其需要注意的是Maven自带的中央仓库使用的id为central如果其他的仓库声明也使用该id就会覆盖中央仓库的配置。该配置中的url值指向了仓库的地址一般来说该地址都基于http协议Maven用户都可以在浏览器中打开仓库地址浏览构件。
该例配置中的releases和snapshots元素比较重要它们用来控制Maven对于发布版构件和快照版构件的下载。这里需要注意的是enabled子元素该例中releases的enabled值为true表示开启JBoss仓库的发布版本下载支持而snapshots的enabled值为false表示关闭JBoss仓库的快照版本的下载支持。因此根据该配置Maven只会从JBoss仓库下载发布版的构件而不会下载快照版的构件。
该例中的layout元素值default表示仓库的布局是Maven 2及Maven 3的默认布局而不是Maven 1的布局。
对于releases和snapshots来说除了enabled它们还包含另外两个子元素updatePolicy和checksumPolicy
snapshots
enabledtrue/enabled
updatePolicydaily/updatePolicy
checksumPolicyignore/checksumPolicy
/snapshots元素updatePolicy用来配置Maven从远程仓库检查更新的频率默认的值是daily表示Maven每天检查一次。其他可用的值包括never—从不检查更新always—每次构建都检查更新interval:X—每隔X分钟检查一次更新X为任意整数。
元素checksumPolicy用来配置Maven检查检验和文件的策略。当构件被部署到Maven仓库中时会同时部署对应的校验和文件。在下载构件的时候Maven会验证校验和文件如果校验和验证失败怎么办当checksumPolicy的值为默认的warn时Maven会在执行构建时输出警告信息其他可用的值包括fail—Maven遇到校验和错误就让构建失败ignore—使Maven完全忽略校验和错误。
4.1、远程仓库的认证
大部分远程仓库无须认证就可以访问但有时候出于安全方面的考虑我们需要提供认证信息才能访问一些远程仓库。例如组织内部有一个Maven仓库服务器该服务器为每个项目都提供独立的Maven仓库为了防止非法的仓库访问管理员为每个仓库提供了一组用户名及密码。这时为了能让Maven访问仓库内容就需要配置认证信息。
配置认证信息和配置仓库信息不同仓库信息可以直接配置在POM文件中但是认证信息必须配置在settings.xml文件中。这是因为POM往往是被提交到代码仓库中供所有成员访问的而settings.xml一般只放在本机。因此在settings.xml中配置认证信息更为安全。
假设需要为一个id为my-proj的仓库配置认证信息编辑settings.xml文件见代码清单如下
settings
……
servers
server
idmy-proj/id
usernamerepo-user/username
passwordrepo-pwd/password
/server
/servers
……
/settingsMaven使用settings.xml文件中并不显而易见的servers元素及其server子元素配置仓库认证信息。上面代码清单中该仓库的认证用户名为repo-user认证密码为repo-pwd。这里的关键是id元素settings.xml中server元素的id必须与POM中需要认证的repository元素的id完全一致。换句话说正是这个id将认证信息与仓库配置联系在了一起。
4.2、部署至远程仓库
私服的一大作用是部署第三方构件包括组织内部生成的构件以及一些无法从外部仓库直接获取的构件。无论是日常开发中生成的构件还是正式版本发布的构件都需要部署到仓库中供其他团队成员使用。
Maven除了能对项目进行编译、测试、打包之外还能将项目生成的构建部署到仓库中。首先需要编辑项目的pom.xml文件。配置distributionManagement元素见代码清单如下在POM中配置构件部署地址
project
……
distributionManagement
repository
idproj-releases/id
nameProj Release Repository/name
urlhttp://192.168.1.100/content/repositories/proj-releases/url
/repository
snapshotRepository
idproj-snapshots/id
nameProj Snapshot Repository/name
urlhttp://192.168.1.100/content/repositories/proj-snapshots/url/snapshotRepository
/distributionManagement
……
/projectdistributionManagement包含repository和snapshotRepository子元素前者表示发布版本构件的仓库后者表示快照版本的仓库。这两个元素下都需要配置id、name和url,id为该远程仓库的唯一标识name是为了方便人阅读关键的url表示该仓库的地址。
往远程仓库部署构件的时候往往需要认证。配置认证的方式已在上节中详细阐述简而言之就是需要在settings.xml中创建一个server元素其id与仓库的id匹配并配置正确的认证信息。不论从远程仓库下载构件还是部署构件至远程仓库当需要认证的时候配置的方式是一样的。
配置正确后在命令行运行mvn clean deploy,Maven就会将项目构建输出的构件部署到配置对应的远程仓库如果项目当前的版本是快照版本则部署到快照版本仓库地址否则就部署到发布版本仓库地址。如下是部署一个快照版本的输出
[INFO] Retrieving previous build number from proj-snapshotsUploading:http:192.168.1.100 contentrepositoriesproj-snapshotscomjuvenmvnbookaccountaccount-email1.0.0-SNAPSHOTaccount-email-1.0.0-20100103.150936-2.jar6 KB uploaded at 727.8 KBsec
[INFO] Retrieving previous metadata from proj-snapshots
[INFO] Uploading repository metadata for: artifact com.juven.mvnbook.account:account-email
[INFO] Uploading project information for account-email 1.0.0-20100103.150936-2
[INFO] Retrieving previous metadata from proj-snapshots
[INFO] Uploading repository metadata for: snapshot com.juven.mvnbook.account:account-email:1.0.0-SNAPSHOT
[INFO]
[INFO] BUILD SUCCESS
[INFO] 5、快照版本
在Maven的世界中任何一个项目或者构件都必须有自己的版本。版本的值可能是1.0.0、1.3-alpha-4、2.0、2.1-SNAPSHOT或者2.1-20091214.221414-13。其中1.0.0、1.3-alpha-4和2.0是稳定的发布版本而2.1-SNAPSHOT和2.1-20091214.221414-13是不稳定的快照版本。
Maven为什么要区分发布版和快照版呢简单的1.0.0、1.2、2.1等不就够了吗为什么还要有2.1-SNAPSHOT甚至是长长的2.1-20091214.221414-13试想一下这样的情况小张在开发模块A的2.1版本该版本还未正式发布与模块A一同开发的还有模块B它由小张的同事季MM开发B的功能依赖于A。在开发的过程中小张需要经常将自己最新的构建输出交给季MM供她开发和集成调试问题是这个工作如何进行呢
1.方案一 让季MM自己签出模块A的源码进行构建。这种方法能够确保季MM得到模块A的最新构件不过她不得不去构建模块A。多了一些版本控制和Maven操作还不算当构建A失败的时候她会是一头雾水最后不得不找小张解决。显然这种方式是低效的。
2.方案二 重复部署模块A的2.1版本供季MM下载。虽然小张能够保证仓库中的构件是最新的但对于Maven来说同样的版本和同样的坐标就意味着同样的构件。因此如果季MM在本机的本地仓库包含了模块A的2.1版本构件Maven就不会再对照远程仓库进行更新。除非她每次执行Maven命令之前清除本地仓库但这种要求手工干预的做法显然也是不可取的。
3.方案三 不停更新版本2.1.1、2.1.2、2.1.3……。首先小张和季MM两人都需要频繁地更改POM如果有更多的模块依赖于模块A就会涉及更多的POM更改其次大量的版本其实仅仅包含了微小的差异有时候是对版本号的滥用。
Maven的快照版本机制就是为了解决上述问题。在该例中小张只需要将模块A的版本设定为2.1-SNAPSHOT然后发布到私服中在发布的过程中Maven会自动为构件打上时间戳。比如2.1-20091214.221414-13就表示2009年12月14日22点14分14秒的第13次快照。有了该时间戳Maven就能随时找到仓库中该构件2.1-SNAPSHOT版本最新的文件。这时季MM配置对于模块A的2.1-SNAPSHOT版本的依赖当她构建模块B的时候Maven会自动从仓库中检查模块A的2.1-SNAPSHOT的最新构件当发现有更新时便进行下载。默认情况下Maven每天检查一次更新由仓库配置的updatePolicy控制用户也可以使用命令行-U参数强制让Maven检查更新如mvn clean install-U。
基于快照版本机制小张在构建成功之后才能将构件部署至仓库而季MM可以完全不用考虑模块A的构建并且她能确保随时得到模块A的最新可用的快照构件而这一切都不需要额外的手工操作。
当项目经过完善的测试后需要发布的时候就应该将快照版本更改为发布版本。例如将2.1-SNAPSHOT更改为2.1表示该版本已经稳定且只对应了唯一的构件。相比之下2.1-SNAPSHOT往往对应了大量的带有不同时间戳的构件这也决定了其不稳定性。
快照版本只应该在组织内部的项目或模块间依赖使用因为这时组织对于这些快照版本的依赖具有完全的理解及控制权。项目不应该依赖于任何组织外部的快照版本依赖由于快照版本的不稳定性这样的依赖会造成潜在的危险。也就是说即使项目构建今天是成功的由于外部的快照版本依赖实际对应的构件随时可能变化项目的构建就可能由于这些外部的不受控制的因素而失败。
6、从仓库解析依赖的机制
Maven的依赖机制和Maven仓库这两者是如何具体联系到一起的呢Maven是根据怎样的规则从仓库解析并使用依赖构件的呢
当本地仓库没有依赖构件的时候Maven会自动从远程仓库下载当依赖版本为快照版本的时候Maven会自动找到最新的快照。这背后的依赖解析机制可以概括如下
1当依赖的范围是system的时候Maven直接从本地文件系统解析构件。2根据依赖坐标计算仓库路径后尝试直接从本地仓库寻找构件如果发现相应构件则解析成功。3在本地仓库不存在相应构件的情况下如果依赖的版本是显式的发布版本构件如1.2、2.1-beta-1等则遍历所有的远程仓库发现后下载并解析使用。4如果依赖的版本是RELEASE或者LATEST则基于更新策略读取所有远程仓库的元数据groupId/artifactId/maven-metadata.xml将其与本地仓库的对应元数据合并后计算出RELEASE或者LATEST真实的值然后基于这个真实的值检查本地和远程仓库如步骤2和3。5如果依赖的版本是SNAPSHOT则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml将其与本地仓库的对应元数据合并后得到最新快照版本的值然后基于该值检查本地仓库或者从远程仓库下载。6如果最后解析得到的构件版本是时间戳格式的快照如1.4.1-20091104.121450-121则复制其时间戳格式的文件至非时间戳格式如SNAPSHOT并使用该非时间戳格式的构件。
当依赖的版本不明晰的时候如RELEASE、LATEST和SNAPSHOT,Maven就需要基于更新远程仓库的更新策略来检查更新。在前面提到的仓库配置中有一些配置与此有关首先是releasesenabled和snapshotsenabled只有仓库开启了对于发布版本的支持时才能访问该仓库的发布版本构件信息对于快照版本也是同理其次要注意的是releases和snapshots的子元素updatePolicy该元素配置了检查更新的频率每日检查更新、永远检查更新、从不检查更新、自定义时间间隔检查更新等。最后用户还可以从命令行加入参数-U强制检查更新使用参数后Maven就会忽略updatePolicy的配置。
当Maven检查完更新策略并决定检查依赖更新的时候就需要检查仓库元数据maven-metadata.xml。
回顾一下前面提到的RELEASE和LATEST版本它们分别对应了仓库中存在的该构件的最新发布版本和最新版本包含快照而这两个“最新”是基于groupId/artifactId/maven-metadata.xml计算出来的见代码清单如下基于groupId和artifactId的maven-metadata.xml
?xml version1.0encodingUTF-8?
metadata
groupIdorg.sonatype.nexus/groupId
artifactIdnexus/artifactId
versioninglatest1.4.2-SNAPSHOT/latest
release1.4.0/release
versions
version1.3.5/version
version1.3.6/version
version1.4.0-SNAPSHOT/version
version1.4.0/version
version1.4.0.1-SNAPSHOT/version
version1.4.1-SNAPSHOT/version
version1.4.2-SNAPSHOT/version
/versions
lastUpdated20091214221557/lastUpdated
/versioning
/metadata该XML文件列出了仓库中存在的该构件所有可用的版本同时latest元素指向了这些版本中最新的那个版本该例中是1.4.2-SNAPSHOT。而release元素指向了这些版本中最新的发布版本该例中是1.4.0。Maven通过合并多个远程仓库及本地仓库的元数据就能计算出基于所有仓库的latest和release分别是什么然后再解析具体的构件。
需要注意的是在依赖声明中使用LATEST和RELEASE是不推荐的做法因为Maven随时都可能解析到不同的构件可能今天LATEST是1.3.6明天就成为1.4.0-SNAPSHOT了且Maven不会明确告诉用户这样的变化。当这种变化造成构建失败的时候发现问题会变得比较困难。RELEASE因为对应的是最新发布版构建还相对可靠LATEST就非常不可靠了为此Maven 3不再支持在插件配置中使用LATEST和RELEASE。如果不设置插件版本其效果就和RELEASE一样Maven只会解析最新的发布版本构件。不过即使这样也还存在潜在的问题。例如某个依赖的1.1版本与1.2版本可能发生一些接口的变化从而导致当前Maven构建的失败。
当依赖的版本设为快照版本的时候Maven也需要检查更新这时Maven会检查仓库元数据groupId/artifactId/version/maven-metadata.xml见代码清单如下基于groupId、artifactId和version的maven-metadata.xml
?xml version1.0encodingUTF-8?
metadata
groupIdorg.sonatype.nexus/groupId
artifactIdnexus/artifactId
version1.4.2-SNAPSHOT/version
versioning
snapshot
timestamp20091214.221414/timestamp
buildNumber13/buildNumber
/snapshot
lastUpdated20091214221558/lastUpdated
/versioning
/metadata该XML文件的snapshot元素包含了timestamp和buildNumber两个子元素分别代表了这一快照的时间戳和构建号基于这两个元素可以得到该仓库中此快照的最新构件版本实际为1.4.2-20091214.221414-13。通过合并所有远程仓库和本地仓库的元数据Maven就能知道所有仓库中该构件的最新快照。
最后仓库元数据并不是永远正确的有时候当用户发现无法解析某些构件或者解析得到错误构件的时候就有可能是出现了仓库元数据错误这时就需要手工地或者使用工具如Nexus对其进行修复。
7、镜像
如果仓库X可以提供仓库Y存储的所有内容那么就可以认为X是Y的一个镜像。换句话说任何一个可以从仓库Y获得的构件都能够从它的镜像中获取。举个例子http://maven.net.cn/content/groups/public/是中央仓库http://repo1.maven.org/maven2/在中国的镜像由于地理位置的因素该镜像往往能够提供比中央仓库更快的服务。因此可以配置Maven使用该镜像来替代中央仓库。编辑settings.xml见代码清单如下 配置中央仓库镜像
settings
……
mirrors
mirror
idmaven.net.cn/id
nameone of the central mirrors in China/name
urlhttp://maven.net.cn/content/groups/public//url
mirrorOfcentral/mirrorOf
/mirror
/mirrors
……
/settings该例中mirrorOf的值为central表示该配置为中央仓库的镜像任何对于中央仓库的请求都会转至该镜像用户也可以使用同样的方法配置其他仓库的镜像。另外三个元素id、name、url与一般仓库配置无异表示该镜像仓库的唯一标识符、名称以及地址。类似地如果该镜像需要认证也可以基于该id配置仓库认证。
关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库包括中央仓库因此对于组织内部的Maven用户来说使用一个私服地址就等于使用了所有需要的外部仓库这可以将配置集中到私服从而简化Maven本身的配置。在这种情况下任何需要的构件都可以从私服获得私服就是所有仓库的镜像。这时可以配置这样的一个镜像见代码清单如下配置使用私服作为镜像
settings
……
mirrors
mirror
idinternal-repository/id
nameInternal Repository Manager/name
urlhttp://192.168.1.100/maven2//url
mirrorOf*/mirrorOf
/mirror
/mirrors
……
/settings该例中mirrorOf的值为星号表示该配置是所有Maven仓库的镜像任何对于远程仓库的请求都会被转至http://192.168.1.100/maven2/。如果该镜像仓库需要认证则配置一个id为internal-repository的server即可。
为了满足一些复杂的需求Maven还支持更高级的镜像配置
mirrorOf*/mirrorOf匹配所有远程仓库。mirrorOfexternal*/mirrorOf匹配所有远程仓库使用localhost的除外使用file://协议的除外。也就是说匹配所有不在本机上的远程仓库。mirrorOfrepo1repo2/mirrorOf匹配仓库repo1和repo2使用逗号分隔多个远程仓库。mirrorOf*repo1/mirrorOf匹配所有远程仓库repo1除外使用感叹号将仓库从匹配中排除。
需要注意的是由于镜像仓库完全屏蔽了被镜像仓库当镜像仓库不稳定或者停止服务的时候Maven仍将无法访问被镜像仓库因而将无法下载构件。
8、仓库搜索服务
使用Maven进行日常开发的时候一个常见的问题就是如何寻找需要的依赖我们可能只知道需要使用类库的项目名称但添加Maven依赖要求提供确切的Maven坐标。这时就可以使用仓库搜索服务来根据关键字得到Maven坐标。本节介绍几个常用的、功能强大的公共Maven仓库搜索服务。
8.1、Sonatype Nexus
地址http://repository.sonatype.org/ 这里要介绍的是Sonatype架设的一个公共Nexus仓库实例。
Nexus提供了关键字搜索、类名搜索、坐标搜索、校验和搜索等功能。搜索后页面清晰地列出了结果构件的坐标及所属仓库。用户可以直接下载相应构件还可以直接复制已经根据坐标自动生成的XML依赖声明
8.2、Jarvana
地址http://www.jarvana.com/jarvana/ Jarvana提供了基于关键字、类名的搜索构件下载、依赖声明片段等功能也一应俱全。值得一提的是Jarvana还支持浏览构件内部的内容。此外Jarvana还提供了便捷的Java文档浏览的功能。Jarvana的搜索结果页面如下图所示
8.3、MVNbrowser
地址http://www.mvnbrowser.com
MVNbrowser只提供关键字搜索的功能除了提供基于坐标的依赖声明代码片段等基本功能之外MVNbrowser的一大特色就是能够告诉用户该构件的依赖于其他哪些构件Dependencies以及该构件被哪些其他构件依赖Referenced By如下图所示
8.4、MVNrepository
地址http://mvnrepository.com/
MVNbrowser只提供关键字搜索的功能除了提供基于坐标的依赖声明代码片段等基本功能之外MVNbrowser的一大特色就是能够告诉用户该构件的依赖于其他哪些构件Dependencies以及该构件被哪些其他构件依赖Referenced By如下图所示
8.5、选择合适的仓库搜索服务
上述介绍的四个仓库搜索服务都代理了主流的Maven公共仓库如central、JBoss、Java.net等。这些服务都提供了完备的搜索、浏览、下载等功能区别只在于页面风格和额外功能。例如Nexus提供了其他三种服务所没有的基于校验和搜索的功能。用户可以根据喜好和特殊需要选择最合适自己的搜索服务当然也可以综合使用所有这些服务。
9、总结
阐述了仓库这一Maven核心概念。首先介绍了仓库的由来接着直接剖析了一段Maven源码介绍仓库的布局以方便读者将仓库与实际文件联系起来而仓库的分类这一部分则分别介绍了本地仓库、远程仓库、中央仓库以及私服等概念基于这些概念又详细介绍了仓库的配置在此基础上我们再深入仓库的内部工作机制并同时解释了Maven中快照的概念。还解释了镜像的概念及用法。最后介绍了一些常用的仓库搜索服务以方便我们的日常开发工作。
