maven 国内可用仓库 maven公司仓库

---

• 何为Maven仓库
• 仓库的布局
• 仓库的分类

• 1 本地仓库
• 2 远程仓库
• 3 中央仓库
• 4 私服

• 远程仓库的配置

• 1 远程仓库的认证
• 2 部署至远程仓库

• 从仓库解析依赖的机制
• 镜像
• 仓库搜索服务

• 1 Sonatype Nexus
• 2 Jarvana
• 3 MVNbrowser
• 4 MVNrepository

---

坐标和依赖是任何一个构件在Maven世界中的逻辑表示方式；而构件的物理表示方式是文件，Maven通过仓库来统一管理这些文件。

1.何为Maven仓库

在Maven世界中，任何一个依赖、插件或者项目构建的输出，都可以称为构件。例如，依赖log4j-1.2.15.jar是一个构件，插件maven-compiler-plugin-2.0.2.jar是一个构件。任何一个构件都有一组坐标唯一标识。

得益于坐标机制，任何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的源码，如下所示：

private static final char PATH_SEPARATOR=′/′;
private static final char GROUP_SEPARATOR=′.′;
private static final char ARTIFACT_SEPARATOR=′-′;

public String pathOf(Artifact artifact) {   

  ArtifactHandler artifactHandler = artifact.getArtifactHandler();   
  StringBuilder path = new StringBuilder(128); 

  path.append(formatAsDirectory(artifact.getGroupId()))
    .append( PATH_SEPARATOR );   
  path.append(artifact.getArtifactId()).append(PATH_SEPARATOR);   
  path.append(artifact.getBaseVersion()).append(PATH_SEPARATOR);   
  path.append(artifact.getArtifactId())
    .append(ARTIFACT_SEPARATOR).append(artifact.getVersion());   

  if (artifact.hasClassifier()) {     
    path.append(ARTIFACT_SEPARATOR)
      .append( artifact.getClassifier());   
  }

  if (artifactHandler.getExtension() != null 
    && artifactHandler.getExtension().length() > 0){     
    path.append(GROUP_SEPARATOR)
      .append(artifactHandler.getExtension());   
  }

  return path.toString();

}

private String formatAsDirectory(String directory) {   
  return directory.replace(GROUP_SEPARATOR, PATH_SEPARATOR);
}

该pathOf()方法的目的是根据构件信息生成其在仓库中的路径。

这里根据一个实际的例子来分析路径的生成，考虑这样一个构件：groupId=org.testng、artifactId=testng、version=5.8、clas-sifier=jdk15、packaging=jar，其对应的路径按如下步骤生成：

1）基于构件的groupId准备路径，formatAsDirectory()将groupId中的句点分隔符转换成路径分隔符。该例中，groupIdorg.testng就会被转换成org/testng，之后再加一个路径分隔符斜杠，那么，org.testng就成为了org/testng/。

2）基于构件的artifactId准备路径，也就是在前面的基础上加上artifactId以及一个路径分隔符。该例中的artifactId为testng，那么，在这一步过后，路径就成为了org/testng/testng/。

3）使用版本信息。在前面的基础上加上version和路径分隔符。该例中版本是5.8，那么路径就成为了org/testng/tes-gng/5.8/。

4）依次加上artifactId，构件分隔符连字号，以及version，于是构建的路径就变成了org/testng/testng/5.8/testng-5.8。这里使用了artifactId.getVersion()，而上一步用的是artifactId.getBaseVersion()，baseVersion主要是为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无法获得项目声明的依赖时，可以查看该依赖对应的文件在仓库中是否存在，如果不存在，查看是否有其他版本可用，等等。

3.仓库的分类

对于Maven来说，仓库只分为两类：本地仓库和远程仓库。当Maven根据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在此构件，则直接使用；如果本地仓库不存在此构件，或者需要查看是否有更新的构件版本，Maven就会去远程仓库查找，发现需要的构件之后，下载到本地仓库再使用。如果本地仓库和远程仓库都没有需要的构件，Maven就会报错。

在这个最基本分类的基础上，还有必要介绍一些特殊的远程仓库。

中央仓库是Maven核心自带的远程仓库，它包含了绝大部分开源的构件。在默认配置下，当本地仓库没有Maven需要的构件的时候，它就会尝试从中央仓库下载。

私服是另一种特殊的远程仓库，为了节省带宽和时间，应该在局域网内架设一个私有的仓库服务器，用其代理所有外部的远程仓库。内部的项目还能部署到私服上供其他项目使用。

除了中央仓库和私服，还有很多其他公开的远程仓库，常见的有Java.net Maven库和JBoss Maven库等。

3.1 本地仓库

一般来说，在Maven项目目录下，没有诸如lib/这样用来存放依赖文件的目录。当Maven在执行编译或测试时，如果需要使用依赖文件，它总是基于坐标使用本地仓库的依赖文件。

默认情况下，不管是在Windows还是Linux上，每个用户在自己的用户目录下都有一个路径名为.m2/repository/的仓库目录。

有时候，因为某些原因（例如C盘空间不够），用户会想要自定义本地仓库目录地址。这时，可以编辑文件~/.m2/settings.xml，设置localRepository元素的值为想要的仓库地址。例如：

<settings>   
    <localRepository>D:\java\repository\</localRepository>
</settings>

这样，该用户的本地仓库地址就被设置成了D:\java\repository\。

需要注意的是，默认情况下~/.m2/settings.xml文件是不存在的，用户需要从Maven安装目录复制$M2_HOME/conf/set-tings.xml文件再进行编辑。

一个构件只有在本地仓库中之后，才能由其他Maven项目使用，那么构件如何进入到本地仓库中呢？最常见的是依赖Maven从远程仓库下载到本地仓库中。还有一种常见的情况是，将本地项目的构件安装到Maven仓库中。例如，本地有两个项目A和B，两者都无法从远程仓库获得，而同时A又依赖于B，为了能构建A，B就必须首先得以构建并安装到本地仓库中。在某个项目中执行mvn clean install命令，就能将本地项目的构件安装到Maven仓库中。

Install插件的install目标将项目的构建输出文件安装到本地仓库。Maven使用Install插件将该文件复制到本地仓库中，具体的路径根据坐标计算获得。

3.2 远程仓库

安装好Maven后，如果不执行任何Maven命令，本地仓库目录是不存在的。当用户输入第一条Maven命令之后，Maven才会创建本地仓库，然后根据配置和需要，从远程仓库下载构件至本地仓库。

Maven需要构件的时候先从本地仓库找。当Maven无法从本地仓库找到需要的构件的时候，就会从远程仓库下载构件至本地仓库。对于Maven来说，每个用户只有一个本地仓库，但可以配置访问很多远程仓库。

3.3 中央仓库

由于最原始的本地仓库是空的，Maven必须知道至少一个可用的远程仓库，才能在执行Maven命令的时候下载到需要的构件。中央仓库就是这样一个默认的远程仓库，Maven的安装文件自带了中央仓库的配置。使用解压工具打开jar文件$M2_HOME/lib/maven-model-builder-3.0.jar，然后访问路径org/apache/maven/model/pom-4.0.0.xml，可以看到如下的配置：

<repositories>  
  <repository>    
    <id>central</id>    
    <name>Maven Repository Switchboard</name>    
    <url>http://repo1.maven.org/maven2</url>    
    <layout>default</layout>   
    <snapshots>      
      <enabled>false</enabled>    
    </snapshots>  
  </repository>
 </repositories>

包含这段配置的文件是所有Maven项目都会继承的超级POM。这段配置使用central作为id对中央仓库进行唯一标识，其名称为Maven Repository Switchboard，它使用default仓库布局。需要注意的是snapshots元素，其子元素enabled的值为false，表示不从该中央仓库下载快照版本的构件。

中央仓库包含了这个世界上绝大多数流行的开源Java构件，以及源码、作者信息、SCM、信息、许可证信息等。由于中央仓库包含了超过2000个开源项目的构件，因此，一般来说，一个简单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中配置该仓库，如下所示：

<project>  
  ...  
  <repositories>    
    <repository>      
      <id>jboss</id>      
      <name>JBoss Repository</name>      
      <url>http://repository.jboss.com/maven2/</url>      
      <releases>         
        <enabled>true</enabled>      
      </releases>      
      <snapshots>         
        <enabled>false</enabled>      
      </snapshots>      
      <layout>default</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表示仓库的布局是默认布局。对于releases和snapshots来说，除了enabled，它们还包含另外两个子元素updatePolicy和checksumPolicy：

<snapshots>  
  <enabled>true</enabled>  
  <updatePolicy>daily</updatePolicy> 
  <checksumPolicy>ignore</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 远程仓库的认证

大部分远程仓库无须认证就可以访问，但有时候出于安全方面的考虑，我们需要提供认证信息才能访问一些远程仓库。

配置认证信息和配置仓库信息不同，仓库信息可以直接配置在POM文件中，但是认证信息必须配置在settings.xml文件中。这是因为POM往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只放在本机。因此，在settings.xml中配置认证信息更为安全。

假设需要为一个id为my-proj的仓库配置认证信息，编辑settings.xml文件如下所示：

<settings> 
  ... 
  <servers>  
    <server>   
      <id>my-proj</id>   
      <username>repo-user</username>   
      <password>repo-pwd</password> 
    </server> 
  </servers> 
  ...
</settings>

Maven使用settings.xml文件中并不显而易见的servers元素及其server子元素配置仓库认证信息。这里的关键是id元素，settings.xml中server元素的id必须与POM中需要认证的repository元素的id完全一致。换句话说，正是这个id将认证信息与仓库配置联系在了一起。

4.2 部署至远程仓库

私服的一大作用是部署第三方构件，包括组织内部生成的构件以及一些无法从外部仓库直接获取的构件。无论是日常开发中生成的构件，还是正式版本发布的构件，都需要部署到仓库中，供其他团队成员使用。

Maven除了能对项目进行编译、测试、打包之外，还能将项目生成的构建部署到仓库中。首先，需要编辑项目的pom.xml文件。配置distributionManagement元素如下所示：

<project> 
  ... 
  <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> 
  ...
</project>

distributionManagement包含repository和snapshotRepository子元素，前者表示发布版本构件的仓库，后者表示快照版本的仓库。这两个元素下都需要配置id、name和url，id为该远程仓库的唯一标识，name是为了方便人阅读，关键的url表示该仓库的地址。

往远程仓库部署构件的时候，往往需要认证。配置认证的方式已在第4.1节中详细阐述，简而言之，就是需要在settings.xml中创建一个server元素，其id与仓库的id匹配，并配置正确的认证信息。不论从远程仓库下载构件，还是部署构件至远程仓库，当需要认证的时候，配置的方式是一样的。

配置正确后，在命令行运行mvn clean deploy，Maven就会将项目构建输出的构件部署到配置对应的远程仓库，如果项目当前的版本是快照版本，则部署到快照版本仓库地址，否则就部署到发布版本仓库地址。

5.从仓库解析依赖的机制

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就需要基于更新远程仓库的更新策略来检查更新。仓库配置中，有一些配置与此有关：首先是和，只有仓库开启了对于发布版本的支持时，才能访问该仓库的发布版本构件信息，对于快照版本也是同理；其次要注意的是和的子元素，该元素配置了检查更新的频率，每日检查更新、永远检查更新、从不检查更新、自定义时间间隔检查更新等。最后，用户还可以从命令行加入参数-U，强制检查更新，使用参数后，Maven就会忽略的配置。

当Maven检查完更新策略，并决定检查依赖更新的时候，就需要检查仓库元数据maven-metadata.xml。

前面提到的RELEASE和LATEST版本，它们分别对应了仓库中存在的该构件的最新发布版本和最新版本（包含快照），而这两个“最新”是基于groupId/artifactId/maven- metadata.xml计算出来的，下面是一个maven-metadata,xml文件的示例：

<?xml version="1.0" encoding="UTF-8"?>
<metadata>  
  <groupId>org.sonatype.nexus</groupId>  
  <artifactId>nexus</artifactId>  
  <versioning>    
    <latest>1.4.2-SNAPSHOT</latest>    
    <release>1.4.0</release>    
    <versions>      
      <version>1.3.5</version>      
      <version>1.3.6</version>      
      <version>1.4.0-SNAPSHOT</version>      
      <version>1.4.0</version>      
      <version>1.4.0.1-SNAPSHOT</version>      
      <version>1.4.1-SNAPSHOT</version>      
      <version>1.4.2-SNAPSHOT</version>    
    </versions>    
    <lastUpdated>20091214221557</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不会明确告诉用户这样的变化。当这种变化造成构建失败的时候，发现问题会变得比较困难。

当依赖的版本设为快照版本的时候，Maven也需要检查更新，这时，Maven会检查仓库元数据groupId/artifactId/ver-sion/maven-metadata.xml，详见如下示例：

<?xml version="1.0" encoding="UTF-8"?>
<metadata> 
  <groupId>org.sonatype.nexus</groupId> 
  <artifactId>nexus</artifactId> 
  <version>1.4.2-SNAPSHOT</version> 
  <versioning>  
    <snapshot>    
      <timestamp>20091214.221414</timestamp>    
      <buildNumber>13</buildNumber>  
    </snapshot>  
    <lastUpdated>20091214221558</lastUpdated> 
  </versioning>
</metadata>

该XML文件的snapshot元素包含了timestamp和buildNumber两个子元素，分别代表了这一快照的时间戳和构建号，基于这两个元素可以得到该仓库中此快照的最新构件版本实际为1.4.2-20091214.221414-13。通过合并所有远程仓库和本地仓库的元数据，Maven就能知道所有仓库中该构件的最新快照。

最后，仓库元数据并不是永远正确的，有时候当用户发现无法解析某些构件，或者解析得到错误构件的时候，就有可能是出现了仓库元数据错误，这时就需要手工地，或者使用工具（如Nexus）对其进行修复。

6.镜像

如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何一个可以从仓库Y获得的构件，都能够从它的镜像中获取。

举个例子，http://maven.net.cn/content/groups/public/是中央仓库http://repo1.maven.org/maven2/在中国的镜像，由于地理位置的因素，该镜像往往能够提供比中央仓库更快的服务。因此，可以配置Maven使用该镜像来替代中央仓库。编辑settings.xml，如下所示：

<settings> 
  ... 
  <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>

该例中，的值为central，表示该配置为中央仓库的镜像，任何对于中央仓库的请求都会转至该镜像，用户也可以使用同样的方法配置其他仓库的镜像。另外三个元素id、name、url与一般仓库配置无异，表示该镜像仓库的唯一标识符、名称以及地址。类似地，如果该镜像需要认证，也可以基于该id配置仓库认证。

关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库（包括中央仓库），因此，对于组织内部的Maven用户来说，使用一个私服地址就等于使用了所有需要的外部仓库，这可以将配置集中到私服，从而简化Maven本身的配置。在这种情况下，任何需要的构件都可以从私服获得，私服就是所有仓库的镜像。这时，可以配置这样的一个镜像，如下所示：

<settings> 
  ... 
  <mirrors>  
    <mirror>    
      <id>internal-repository</id>    
      <name>Internal Repository Manager</name>    
      <url>http://192.168.1.100/maven2/</url>    
      <mirrorOf>*</mirrorOf>  
    </mirror> 
  </mirrors> 
  ...
</settings>

该例中的值为星号，表示该配置是所有Maven仓库的镜像，任何对于远程仓库的请求都会被转至http://192.168.1.100/maven2/。如果该镜像仓库需要认证，则配置一个id为internal-repository的即可。

为了满足一些复杂的需求，Maven还支持更高级的镜像配置：

*：匹配所有远程仓库。
external:*：匹配所有远程仓库，使用localhost的除外，使用file://协议的除外。也就是说，匹配所有不在本机上的远程仓库。
•repo1,repo2：匹配仓库repo1和repo2，使用逗号分隔多个远程仓库。
•*,!repo1：匹配所有远程仓库，repo1除外，使用感叹号将仓库从匹配中排除。

需要注意的是，由于镜像仓库完全屏蔽了被镜像仓库，当镜像仓库不稳定或者停止服务的时候，Maven仍将无法访问被镜像仓库，因而将无法下载构件。

7.仓库搜索服务

使用Maven进行日常开发的时候，一个常见的问题就是如何寻找需要的依赖，我们可能只知道需要使用类库的项目名称，但添加Maven依赖要求提供确切的Maven坐标。这时，就可以使用仓库搜索服务来根据关键字得到Maven坐标。下面介绍几个常用的、功能强大的公共Maven仓库搜索服务。

7.1 Sonatype Nexus

地址：http://repository.sonatype.org/

Nexus是当前最流行的开源Maven仓库管理软件，这里要介绍的是Sonatype架设的一个公共Nexus仓库实例。

Nexus提供了关键字搜索、类名搜索、坐标搜索、校验和搜索等功能。搜索后，页面清晰地列出了结果构件的坐标及所属仓库。用户可以直接下载相应构件，还可以直接复制已经根据坐标自动生成的XML依赖声明。

7.2 Jarvana

Jarvana提供了基于关键字、类名的搜索，构件下载、依赖声明片段等功能也一应俱全。值得一提的是，Jarvana还支持浏览构件内部的内容。此外，Jarvana还提供了便捷的Java文档浏览的功能。

7.3 MVNbrowser

MVNbrowser只提供关键字搜索的功能，除了提供基于坐标的依赖声明代码片段等基本功能之外，MVNbrowser的一大特色就是，能够告诉用户该构件的依赖于其他哪些构件（Dependen-cies）以及该构件被哪些其他构件依赖（Referenced By）。

7.4 MVNrepository

地址：http://mvnrepository.com/

MVNrepository的界面比较清新，它提供了基于关键字的搜索、依赖声明代码片段、构件下载、依赖与被依赖关系信息、构件所含包信息等功能。MVNrepository还能提供一个简单的图表，显示某个构件各版本间的大小变化。