maven---6仓库

|-1-更新内容[6.从仓库解析依赖的机制(重要)]

1Maven仓库作用

仓库用来存储所有项目使用到构件,在maven项目需要依赖时就从该仓库中获取需要的依赖添加到classpath供其使用。

1.1需求背景

  • 非maven项目如果要使用依赖,在其项目目录下有一个lib文件夹,用来存放当前项目依赖的构件或者架包。这样就存在一个问题,如果一个电脑上有10个项目,每个项目依赖的架包都有重复的,那么就会存在把相同架包在每个项目的lib目录下都拷贝一份的情况,当公司需要统一换掉一个架包时就需要把每个项目的该架包都删掉在重新拷贝。由此可见问题有2个。1是每个项目都有lib文件夹造成磁盘空间浪费。2最重要的是不能统一管理所有的依赖。

  • maven仓库就是用来解决上述问题的,所有的maven项目下都没有lib文件夹,也就是maven项目不再各自存储其依赖文件,它们只需要声明这些依赖的坐标,在需要的时候(例如,编译项目的时候需要将依赖加入到classpath中),Maven会自动根据坐标到仓库中找构件,并使用它们

  • 为了实现重用,项目构建完毕后生成的构件也可以安装或部署到仓库中,供其他门项目使用。

2Maven仓库布局

2.1布局规则

  • 仓库一个文件系统,里面存放个下载的所有依赖文件,那么这些依赖在仓库中是按照什么样规则存储布局*的呢?

  • 任何构件都有其唯一的坐标,根据这个坐标可以定义在仓库中的唯一存储路径
    路径规则:groupId/artifactId/version/artifactId-verson.packaging。
    比如:log4j:log4j:1.2.15这一依赖,在仓库的对应路径为: log4j/log4j/1.2.15/log4j-1.2.15.jar。

2.2本地仓库中依赖文件夹中其它文件解释

log4j-1.2.15.jar在本地仓库存储路径

log4j-1.2.15.pom:log4j-1.2.15.jar依赖的pom文件,该文件在log4j-1.2.15.jar文件解压后也能得到,只是名称为pom.xml。
_remote.repositories:该文件所在的远程仓库信息。
log4j-1.2.15.jar.sha1:log4j-1.2.15.jar文件的校验和文件,log4j-1.2.15.jar文件下载后为了验证下载内容是否完整,需要使用log4j-1.2.15.jar.sha1中的校验和值来比对。如果下载内容不完整(网络原因等)maven会作出相应通知。(下面远程仓库配置有讲解)
log4j-1.2.15.pom.sha1:log4j-1.2.15.pom的校验和文件。

3仓库的分类

3.1介绍

  • 仓库分为两种,远程仓库和本地仓库,maven根据坐标寻找构件时,会先在本地仓库查找,本地找不到会到远程仓库查找,找到后会下载到本地仓库,如果本地和远程仓库都找不到就会报错。

  • 本地仓库在本地计算机上。

  • 远程仓库和本地仓库相对。

  • 中央仓库是Maven很想自带的远程仓库,它包含了大部分开源构件,默认配置下,当本地仓库找不到构件就去远程仓库下载,其中的远程仓库默认就是中央仓库。此时需要连接外网下载构件,下载构件的时间会受网络的影响。

  • 私服是一种特殊的远程仓库,为了节省带宽时间,应该在局域网内假设一个私有的仓库服务器,用其代理所有外部的远程仓库,内部项目在本地找不到时就到私服上下载,因为是公司内部网络下载起来就好很快,如果私服上没有,私服就会通过代理去下载。内部的项目还能部署到私服上供其他项目使用。

  • 其它公开的远程仓库,常见的有JBoss Maven库Java.net Maven库等。

maven仓库的分类

3.2本地仓库

3.2.1本地仓库位置

  • 本地仓库默认位置在${user.home}/.m2/repository目录下。我的用户名为liang,则本地仓库地址为C:\Users\liang.m2\repository\,而Linux上的本地仓库地址为home/liang/.m2/repository/注意Liunx中以点(.)开头的文件或目录默认隐藏的,可以使用ls-a命令查看。

3.2.2修改本地仓库位置

3.2.2三种方式添加构件到本地仓库

3.2.2.1从远程仓库下载下来。

通过在项目的pom中配置依赖,dependency下载需要的依赖到本地仓库。

3.2.2.2 通过maven命令安装maven项目到本体仓库

  • 在某个maven项目根目录下执行:mvn clean install命令就可以把项目以构件形式安装到本地仓库中。(部署到私服上执行mvn clean deploy后面讲)

3.2.2.3安装第三方构件到本地仓库

  • 第三方,只是一个jar包,出现这种情况:别人开发好的一个jar包,但是没有发布到maven中央仓库中,我需要在maven项目中使用,所以,我们可以通过命令将该jar包添加到本地仓库中,这样就可以在项目中声明使用了,声明一个构件当然需要groupId\artifactId、version。
  • 需求:把jar:g:\edu.mit.jwi_2.3.3_jdk.jar 安装到本地仓库,并且自定义它的gourpId=local.edu.stanford; artifactId=edu.mit.jwi_jdk;version=2.3.3;packaging =jar
  • 操作:在命令行中执行如下命令即可。详见:install:install-file
mvn install:install-file -Dfile=g:\edu.mit.jwi_2.3.3_jdk.jar -DgroupId=local.edu.stanford -DartifactId=edu.mit.jwi_jdk -Dversion=2.3.3 -Dpackaging=jar  -DpomFile=g:\pom.xml

关于部署第三方构件到Nexus私服仓库,请查看maven---9使用Nexus创建私服----->5.3手动部署第三方构件至Nexus

3.3远程仓库

  • 远程仓库相对本地仓库,本地仓库不存在的构件才会从远程仓库下载,并保存在本地仓库中。对maven来说,每个用户只有一个本地仓库,但可以配置访问很多远程仓库。

3.4中央仓库

  • 由于最原始的本地仓库是空的,Maven必须知道至少一个可用的远程仓库,才能在执行maven命令的时候下载需要的构件。中央仓库就是这样一个默认的远程仓库,中央仓库的信息在超级Pom中配置,所有的maven项目都会继承超级POM。 超级POM的位置: $M2_HOME/lib/maven-model-builder-3.0.jar,然后访问路径org/apache/maven/model/pom-4.0.0.xml,可以看到配置:
<repositories>
    <repository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>
  • 解释 使用id=central对仓库进行唯一标识;name仓库名称;url仓库地址;layout=default指定仓库的布局,default也就是上面提到布局规则;enabled=false表示不从该中央仓库下载快照版本的构件。

3.5私服

  • 私服是一种特殊的远程仓库,它是架设在局域网的仓库服务,私服代理广域网上的远程仓库,供局域网使用。

3.5.1架设私服的好处

  • 节省资金的外网带宽,利用私服代理外部仓库之后,对外的重复构件下载便得以下手,降低外网带宽压力。

  • 加速Maven构建。不停地连接请求外部仓库是什么耗时的,但是maven的一些内部机制(如快照更新检查)要求Maven在执行构建的时候不停地检查远程仓库数据。因此,当项目配置了很多外部远程仓库的时候,构建速度会降低。使用私服解决这问题,因为Maven只需要检查局域网内私服的数据时,构建速度便提高。

  • 部署第三方构件,当某个构件无法从任何一个远程仓库获取怎么办?比如Oracle的JDBC驱动由于版权原因不能发布到公共仓库中。建立私服后,便可以将这些构件部署到这个内部仓库中,供内部Maven项目使用。

  • 提高稳定性,增强控制。对于远程仓库当外网不可用时,maven构建有可能因为依赖没有下载而不可行,私服后,即使没有网,如果该构件只有之前被其它人下载过就会存在私服上,此时我下时就可以不用连接外网直接就可以从私服上下载到。同时私服软件(nexus)还提供了额外的管理功能。

  • 降低中央仓库的负荷

4远程仓库配置(包含更新策略)

4.1配置

默认的中央仓库无法满足项目需求,可能需要的构件在另外一个远程仓库,如JBoss Maven仓库,可以POM中配置该仓库。

<repositories>
....
    <repository>
      <id>jboss</id>
      <name>JBoss Repository</name>
      <url>https://repository.jboss.com/maven2/</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
     <releases>
        <enabled>true</enabled>
      </releases>
    </repository>
 ....
  </repositories>

4.1.1解释

  • id要唯一,如果出现重复会覆盖掉之前的。
  • 对于releases的enabled=true表示开启JBoss仓库的发布版本下载支持。根据以上配置,maven只从JBoss仓库下载发布版本的构件不会下载快照版本。
  • 对于releases和snapshots来说,除了enabled还包含两个子元素updataPolicy和checksumPolicy
 <releases>
        <enabled>true</enabled>
        <updataPolicy>daily</updataPolicy>
        <checksumPolicy>warn</checksumPolicy>
    </releases>
  • updataPolicy:配置maven从远程仓库检查更新的频率,对同一个版本(如:log4j.1.2.15.jar)的构件如果发现有更新(如:对log4j.1.2.15.jar进行了内容修复但是版本都不变)会下载最新的。默认daily-maven每天检查一次
    never-从不检查;always-每次构件都要检查更新;interval:X -每隔X分钟检查一次更新(X为整数)
    当然:用户可以使用参数-U,强制检查更新,使用参数后,maven就会忽略updatePolicy的配置。
    至于如何更新请看下面的(6从仓库解析依赖的机制),其中涉及到从远程下载maven-metadata.xml文件。
  • checksumPolicy:用来配置Maven检查校验和文件失败后的策略。构件被部署到maven仓库中时会同时部署对应的校验和文件,maven会验证校验和文件以确定下载的构件是否完整,如果校验失败,怎么办?策略有3中:(默认值)warn-maven会执行构建时输出警告信息;fail-maven遇到校验和错处就让构建失败;ignore-使maven完全忽略校验和错误。

4.2远程仓库的认证

  • 有时候处于安全考虑,需要提供认证信息才能访问一些远程仓库。为了能让maven访问仓库内容,就需要配置认证信息,认证信息的配置不会在pom.xml配置,而是在settings.xml中配置,因为pom会被提交到代码仓库中供所有成员访问,而settings.xml一般只放在本机。
  • 假设我在pom.xml中配置id=my-proj的远程仓库,需要认证信息,则在settings.xml中配置如下:
<settings>
...
   <servers>
    <server>  
          <id>my-proj</id>  
          <username>repo-user</username>  
          <password>repo-pwd</password>  
       </server>  
   </servers>
...
</settings>
  • 这里的id=my-proj一定要和pom.xml中仓库的id一致,这是它们之间唯一的联系。

  • settings.xml的servers中就是用来配服务器授权信息的,当然不仅可以配置仓库服务器认证信息,还可以配置其它的比如tomcat服务器授权信息也可以在这里配置。

4.3部署当前maven项目至远程仓库

4.3.1需求

  • 私服的一个作用是部署公司内部生成的构件以及一些无法从外部仓库获取的构件。那么如何把maven项目部署到私服上或者其他的远程服务器上呢?

4.3.2操作步骤

步骤-1配置pom.xml
需要编写pom.xml文件,配置distributionManagement元素。

<distributionManagement>
    <repository>
        <id>proj-releases</id>
        <name>Proj Release Repository</name>
        <url>http://192.168.1.100/content/repositories/proj-releases</url>
    </repository>
    <snapshotRepository>
        <id>proj-snapshots</id>
        <name>Proj Snapshot Repository</name>
        <url>http://192.168.1.100/content/repositories/proj-snapshots</url>
    </snapshotRepository>
  </distributionManagement>
  • distributionManagement包含repository和snapshotRepository子元素,前者表示发布版本构件的仓库,后者表示快照版本的仓库。
  • id为远程仓库的唯一标识,name是为了方便人阅读,url表示该仓库的地址。

步骤-2配置settings.xml

  • 往仓库部署构件往往需要认证,配置方式如上面所讲,只需要配置settings.xml中的server元素。同时其id要与仓库id匹配。不论部署还是下载构件,当需要认证时配置方式一样。

步骤-3使用部署命令

  • 在命令行运行 mvn clean deploy。Maven就会将项目构建输出的构件部署到配置对应的远程仓库,如果项目版本是快照版本就部署到快照版本仓库地址,同理发布版本仓库地址。

5快照版本

任何一个项目或者构件都必须由自己的版本,1.0.0、1.2-alpha-4、2.0、2.1-SNAPSHOT,其中2.1-SNAPSHOT是不稳定的快照版本。

5.1需求

小张和李MM负责公司同一个项目的不同模块,小张负责A模块,李MM负责B模块,但是B模块的开发过程中依赖A模块,为了保证快速开发,小张的模块A内容的变化应该尽快的让李MM获取到,但是李MM获取小张模块A是通过groupId、artifactId、version来配置获取的,怎样才能获取最新的呢?两人不停的改变版本号? 那么小张和李MM怎么配合开发呢?

5.2方案

  • 方案1:让李MM自己签出模块A的源代码进行构建,这种方法能够确保李MM得到模块A的最新构件,不过她不得去自己构建A,当构建失败时,她会一头雾水不得不去找小张解决,效率低。

  • 方案2:小张重复部署模块A的2.1版供李MM下载。问题:虽然小张能够保证仓库中的构件是最新的,但是对于maven来说,同样的版本就是同样的构件,所以李MM本地仓库包含了A2.1,maven就不会再对仓库进行更新了,除非执行maven命令之前,清除本地仓库,效率低。

  • 方案3:不停更新版本2.1.1、2.1.2、2.1.3 ....。小张和小丽都需要不停的更新Pom,如果更多模块依赖A,就会涉及更多pom更改。这就涉及到两问题:小张更新版本号时要对李MM说一下让她也更新一下。其次是版本号滥用。

  • 方案4(快照):解决上述问题,使用快照机制,该例中,小张只需要将模块A的版本设定为2.1-SNAPSHOT,然后发布到私服中,在发布过程中maven会自动为构件打上时间戳,比如2.1-20161119-105936-12:表示2016年11月19号10点59分36秒第12次修改,有了该时间戳,Maven就能随时找到该仓库中该构件2.1-SNAPSHOT的最新构件。也就是2.1-SNAPSHOT对应了许多带有不同时间戳的构件。李MM这边配置对于模块A的2.1-SNAPSHOT版本,当构建模块B时发现有更新便进行下载,默认情况下,maven每天检查一次更新(由仓库配置的updataPolicy控制,上面有讲),李MM也可以使用命令行-U参数强制maven更新,如:mvn clean install-U 。

    • 基于快照机制,这样小张和李MM就不用不断的修改版本了。小张构建成功后发布到仓库,李MM不用手工操作,她就可以得到A的最新快照版本构件。

5.3使用经验

  • 当项目测试后需要发布时,将快照版改为发布版本。如2.1-SNAPSHOT改为2.1,且只对应唯一构件,而2.1-SNAPSHOT对应了许多带有不同时间戳的构件。

  • 快照版使用场景 快照版只应该在公司内部项目使用,因为项目成员对不同的模块有清晰的理解和控制。项目不应该依赖第三方的快照版构件。那样存在不受控制和不稳定性。

6从仓库解析依赖的机制(重要)

上一节介绍了Maven依赖机制,本章阐述了Maven仓库,这两者是如何具体联系到一起的呢?Maven是根据怎样的规则从仓库解析并使用依赖构件的呢?

6.1解析构件步骤

该步骤适用于插件、依赖的解析

  1. 当依赖范围是system时候,Maven直接从本地文件解析构件。
  2. 根据依赖坐标计算仓库路径后,先从本地仓库寻找构件,如果发现则解析成功。
  3. 本地仓库没找到,如果依赖版本(version)是发布版构件,即1.2,2.3等,则遍历远程仓库,发现后下载并解析使用。
  4. 如果version是SNAPSHOT版,如:2.1-SNAPSHOT,则基于更新策略(updatepolicy)读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml,将其与本地仓库的对应元数据合并后,得到最新快照版本的值,然后基于该值检查本地仓库,或者从远程仓库下载。(如果最新版还是之前的值就不需要去远程仓库下载了)。
    注意:这一步因为updatepolicy的原因,可能要求本机能连接到远程仓库(远程仓库可以是私服或者中央仓库,一般只有自己的项目会使用SNAPSHOT,所以大多数是私服)
  5. 如果最后解析得到构件版本是时间戳格式的快照,如1.4.1-20161121.121432-121则复制其时间戳格式的文件至非时间戳格式,如SNAPSHOT,并使用该时间戳格式的构件。
  6. 当依赖的version值为RELEASE时(不建议),Maven会基于updatepolicy策略读取远程仓库的元数据groupId/artifactId/maven-metadata.xml,将其与本地仓库相对应元数据合并后,计算出最新版本的RELEASE值(稳定版),然后基于这个值检查本地和远程仓库,步骤如2和3。
    注意:存在潜在问题,如某个依赖的1.1版本与1.2版本可能发生一些接口变化,从而导致当前Maven项目构建失败,所以依赖的版本最好确定

注:第4步骤在6.2、6.3节有详解

6.2解析进一步说明

  • 当构件版本version为RELEASE,或为快照版,maven都需要基于仓库配置的更新策略updatePolicy来检查更新最新版本,那么更新策略就是上面4.1、4.1.1所讲的。(其中的仓库可以是存放依赖的仓库也可以是存放插件的仓库),当构件的version有稳定版值(如2.1),而且在本地仓库有该构件后,如果执行的maven命令没有加-U参数,那么根据6.1的解析步骤,在第2步就返回该构件,而不会参照updatePolicy去检查更新

  • 1.首先通过配置某个远程仓库中<releases>、<snapshots>的<enabled>来确定是否支持从该仓库下载发布版本和快照版本构件的支持,如果不支持,则不会下载相应类型的构件(发布版和快照版)。

  • 2.如果第1步通过,在通过配置<releases>、<snapshots>的<updatePolicy>来配置检查更新依赖的频率:每日更新、永远更新、从不更新、自定义时间间隔更新。如果updatePolicy为“从不更新”则不会检查远程仓库该插件的内容是否变化,而是直接使用本地构件。 当然可以通过在命令中加入参数-U,强制检查更新。(使用-U会强制检查更新pom.xml中所有依赖和插件不管version有没有值)。

6.3 快照版和稳定版解析构件详解

6.3.1解析时机

  • 首先maven项目的pom.xml文件中包含该类构件,当在项目上执行的mvn命令会用到该类构件时就会触发解析事件。

6.3.2解析说明

  • 当version值为RELEASE或为快照版时,通过2步来解析得到构件:1.maven需要通过策略来计算得到构件版本的值。2.找到值之后就按照常规的解析步骤解析构件:先在本地仓库找,找不到再到远程仓库找。下面就来介绍第1步。

6.3.3步骤1:获取构件版本值

  • 先判断远程仓库是否支持相应构件(快照版、发布版)下载,不支持则解析失败,支持则再判断updatePolicy指定的更新频率是否到达,如果更新频率没到,则使用上一次更新得到的结果,该结果可能是上次成功的结果也可能是上次解析失败的结果。如果前一次解析失败(网络等原因),则这一次解析返回结果就是上一次失败原因。如果前一次解析成功,则这一次直接返回上一次解析得到的值。
  • 当更新频率达到后则执行步骤2得到具体的构件版本值,如下。

6.3.4步骤2:获取构件版本值

当构件version=RELEASE情况(不建议这么设值)
  • maven会读取所有远程仓库的元数据groupId/artifactId/maven-metadata.xml,将其与本地仓库的对应元数据(本地仓库元数据为为本地最后一次更新该构件从远程仓库下载下来的文件)合并后,得到最新快照版本的值

  • 以nekohtml构件为例,该构件的依赖配置如下:该构件来自于中央仓库,该依赖仓库不支持快照版本,只支持发布本而且更新策略为“每天更新一次”。因为我本地配置了id为nexus-mirror的镜像从私服中下载构件。则nekohtml构件在本地仓库中的元数据文件名为maven-metadata-nexus-mirror.xml,文件内容如下:

<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
  <groupId>net.sourceforge.nekohtml</groupId>
  <artifactId>nekohtml</artifactId>
  <version>1.9.22</version>
  <versioning>
    <latest>1.9.22</latest>
    <release>1.9.22</release>
    <versions>
      <version>1.9.7</version>
      <version>1.9.8</version>
     。。。。。省略其它版本
      <version>1.9.21</version>
      <version>1.9.22</version>
    </versions>
    <lastUpdated>20150417210244</lastUpdated>
  </versioning>
</metadata>
  • 该xml文件列出来仓库中存在该构件的所有版本,同时latest元素指向了这些版本中最新的那个版本(快照版或发布版),为1.9.22,release元素指向了这些版本中最新发布版本。由于不支持快照版,所以该文件中没有快照版本。lastUpdated是构件最新更新的时间,该时间是构件创建者发布该构件到中央仓库的时间。
  • maven在更新时会从所有远程仓库中下载该构件的元数据到本地,然后和本地的进行合并,就可以得到所有仓库中该构件的最新版本值。获取构件版本值成功。
当构件version为快照版情况
  • maven读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml,将其与本地仓库的对应元数据合并后,得到最新快照版本的值,该元数据在version目录下面,而version没有值时检查的元数据在artifactId目录下面。

  • 那么maven如何根据maven-metadata.xml来检查更新快照版的最新构件的版本值的呢?首先明白一个快照版本0.0.1-SNAPSHOT对应多个构件,maven就是找出那个最新的构件。

  • 下面以iqasweb项目为例,该项目version0.0.1-SNAPSHOT。项目在本地仓库元数据文件为maven-metadata-nexus-snapshots.xml,内容如下:

<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
  <groupId>com.cnu.iqas</groupId>
  <artifactId>iqasweb</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <timestamp>20170111.062153</timestamp>
      <buildNumber>4</buildNumber>
    </snapshot>
    <lastUpdated>20170111062153</lastUpdated>
    <snapshotVersions>
      <snapshotVersion>
        <extension>war</extension>
        <value>0.0.1-20170111.062153-4</value>
        <updated>20170111062153</updated>
      </snapshotVersion>
      <snapshotVersion>
        <extension>pom</extension>
        <value>0.0.1-20170111.062153-4</value>
        <updated>20170111062153</updated>
      </snapshotVersion>
      <snapshotVersion>
        <classifier>sources</classifier>
        <extension>jar</extension>
        <value>0.0.1-20170111.062153-4</value>
        <updated>20170111062153</updated>
      </snapshotVersion>
    </snapshotVersions>
  </versioning>
</metadata>
  • 该xml文件的snapshot元素包含的timestamp和buildNumber两个元素代表了快照的时间戳和构建号,即version版本下的第几次构建的,基于这两个元素可以得到该仓库中此快照的最新构件版本实际为0.0.1-20170111.062153-4。lastUpdated是构件最新更新的时间。snapshotVersions标签中内容是构件产生的其它文件的版本标识。
    在nexus私服中可以看到该版本的构件有4个,正好对应4次构建。
iqasweb快照版构件
  • maven读取所有远程仓库的元数据groupId/artifactId/**version/maven-metadata.xml,将其与本地仓库的对应元数据合并后,得到最新快照版本的值。获取版本值成功。

6.4常见解析失败

在根据6.1的执行步骤解析构件时难免因为一些出现一些错误,常见一个错误如下:

  • 解析失败原因
    如果执行到第3步骤,因为一些原因(比如没网络)从远程仓库下载构件失败(不管是私服还是中央仓库),则依赖解析失败。
  • 解析失败情况演示
<dependency>
    <groupId>com.github.docker-java</groupId>
    <artifactId>docker-java</artifactId>
    <version>3.0.4</version>
</dependency>

第一次解析上面依赖因为没网络执行到第3步失败:


解析步骤和失败原因

失败后在本地仓库产生的文件如下:

解析失败产生的文件

docker-java-3.0.4.jar.lastUpdated文件的内容如下:

#NOTE: This is an Aether internal implementation file, its format can be changed without prior notice.
#Mon Jan 09 21:21:29 CST 2017
http\://172.19.201.155\:8081/repository/maven-public/.lastUpdated=1483968089340
http\://172.19.201.155\:8081/repository/maven-public/.error=
  • 解决
    让本机可以连接到远程仓库,在执行编译,结果还是错误,因为maven缓存了上传执行失:
    Paste_Image.png

执行命令加上-U参数,或者将解析失败构件在本地仓库中的xxxx.lastupdated文件删掉,就不会返回缓存了。

下载新构件

7镜像

  • 如果仓库X可以提供仓库Y存储的所有内容,那么就可以认为X是Y的一个镜像。举个栗子:http://maven.net.cn/content/groups/public/ 是中央仓库http://repol.maven.org/maven2/ 在中国的镜像,由于地理位置原因,该镜像提供的下载服务更快。因此可以配置maven使用该镜像来替代中央仓库,编辑settings.xml。
<settings>
  <mirrors>
    <!-- mirror
     | Specifies a repository mirror site to use instead of a given repository. The repository that
     | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
     | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
     |  -->
    <mirror>
      <id>maven.net.cn</id>
      <name>one of the central mirrors in China</name>
      <url>http://maven.net.cn/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
</settings>
  • 该例中mirrorOf为central,表示该配置为中央仓库的镜像,任何对于中央仓库的请求都会转至该镜像,用户也可以使用该方法配置其它仓库的镜像。另外三个参数和配置一般远程仓库一样。
  • 镜像一般用在私服上,因为私服代理了任何外部的公共仓库,因此对于组织内部的maven用户来说,使用一个私服地址就等于使用所有外部仓库。
  • 为满足复杂需求,maven支持更高级的镜像配置。
    • <mirrorOf>*</mirrorOf> :匹配所有远程仓库。
    • <mirrorOf>external:*</mirrorOf> :匹配所有远程仓库,使用localhost的除外,使用file://协议的除外。
    • <mirrorOf>repo1,repo2</mirrorOf> :匹配仓库repo1,repo2,多个使用逗号分隔。
    • <mirrorOf>*,!repo1</mirrorOf> :匹配所有远程仓库,repo1除外。

8仓库搜索服务

我们如何寻找需要的依赖,以下是几个公共Maven仓库搜索服务,都代理了主流的Maven公共仓库,如中央仓库、JBoss、java.net等,搜索关键字有:类名、坐标、校验和搜索等

8.1Sonatype Nexus

Sonatype Nexus

8.2Jarvana

Jarvana

8.3MVNborwser

MVNborwser

8.4MVNrepository

MVNrepository

有什么不懂的一起探讨一下吧,我也是在学习的路上。喜欢给我点个赞吧(哈哈),我会继续努力的。

注意

  • 镜像配置的地址,一般应该是一个包含了多个仓库的仓库组地址,这个仓库组里面应该包含中央仓库、自己的release仓库,自己的snapshot仓库,第三方release仓库等。公司的仓库是个坑。。。,不要配置镜像。

推荐阅读更多精彩内容

  • 目前在看nexus私服章节的知识时需要用到仓库与镜像的知识,正好通过简书把仓库和镜像章节的笔记整理一下 仓库 ma...
    小炼君阅读 285评论 0 3
  • 首先私服是一种衍生出来的特殊的Maven远程仓库,构建私服的好处请看3.5私服 可以帮助大家建立私服的仓库管理软件...
    zlcook阅读 7,432评论 0 33
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 68,653评论 12 116
  • Maven概念模型与依赖解析机制 Maven根据项目的pom.xml文件,把它转化成项目对象模型(POM),这时要...
    梁朋举阅读 920评论 0 6
  • 1.远程仓库的配置 在平时的开发中,我们往往不会使用默认的中央仓库,默认的中央仓库访问的速度比较慢,访问的人或许很...
    followtry阅读 7,123评论 3 4