Maven的坐标以及仓库

  Maven的世界中拥有数量非常巨大的构件，也就是我们平时用的一些jar，war等文件。

1、Maven的坐标

  Maven定义了这样一组规则：

• 世界上任何一个构件都可以使用Maven坐标唯一标识，Maven坐标元素包括：groupId，artifactId，version，package，classifier

  上面定义的POM是Maven 2和3所允许的最小值。groupId:artifactId:version都是必填字段(虽然groupId和version不需要显式地定义是否继承自一个父类——更多的将详细介绍继承)。这三个字段非常类似于一个地址和时间戳。这标志着存储库中的特定位置，就像Maven项目的坐标系统一样。

• groupId：这在组织或项目中通常是独一无二的。例如，所有的核心Maven工件都(应该)在groupId org.apache.maven.中生存。组ID不一定使用点符号，例如，junit项目。注意，点状的groupId不需要与项目包含的包结构相对应。然而，这是一个很好的实践。当存储在一个存储库中时，这个组就像操作系统中的Java打包结构一样。这些点被OS特定的目录分隔符(Unix中的’/’)所取代，这将成为基本存储库的相对目录结构。在给出的示例中，org.codehaus.mojo组的地址是$M2_REPO/org/codehaus/mojo。

• artifactId：artifactId通常是项目名称的名称。尽管groupId很重要，但小组内的人员很少会在讨论中提到这个问题(它们通常都是相同的ID，比如 Codehaus Mojo项目groupId:org.codehaus.mojo)。它和groupId一起创建一个密钥，将这个项目与世界上的其他项目分离(至少它应该是:))。除了groupId，artifactId还完全定义了该构件在存储库中的生存空间。在上述项目中,my-project存在在$M2_REPO/org/codehaus/mojo/my-project。

• version：这是命名难题的最后一部分。groupId:artifactId表示单个项目，但是它们不能描述我们正在讨论的项目的哪个版本。我们想要的是今天的junit:junit(版本4)，还是4年前(版本2)?简而言之:代码更改，这些更改应该被版本化，并且这个元素保持这些版本的一致。它还在工件的存储库中使用，以将不同版本的版本分开。my-project1.0版本文件目录结构存在于$M2_REPO/org/codehaus/mojo/my-project/1.0。

  上面给出的三个元素指向一个特定版本的项目，让Maven知道我们正在处理的是谁，以及在软件生命周期中我们想要的是什么。

• packaging：现在我们有我们地址结构的groupId:artifactId:version,还有一个标准的标签给我们一个真正完整的地址。这就是项目的工件类型。在我们的例子中，在org.codehaus.mojo:my-project:1.0示例的POM中:上面的定义将会被打包成一个jar。我们可以通过宣布不同的打包方式来生成war:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <packaging>war</packaging>
  ...
</project>

  当没有声明任何打包方式时，Maven假定工件是默认的:jar。有效的类型是丛role-hints(阅读更多丛解释的角色和role-hints)org.apache.maven.lifecycle.mapping.LifecycleMapping组件的作用。当前的核心打包值是:pom、jar、maven-plugin、ejb、war、ear、rar、par。这些定义的默认列表致力于为每个为特定的包结构构建生命周期阶段。

• classifier：你可能偶尔会在坐标上找到第五个元素，那就是classifier。稍后我们将参观分类器,但现在,它可以知道这些项目显示为groupId:artifactId:packaging:classifier:version。

2、Maven的仓库

  Maven的仓库种类：

• 本地仓库
• 远程仓库

Maven的依赖项查找逻辑：

  当我们的Maven项目中引入依赖后，Maven项目先在本地的Maven仓库中查找，如果找不到，然后就去远程的Maven仓库中去查找，如果远程的仓库中也找不到，那么Maven就会报错。

Maven默认的仓库地址链接存放位置：

  Maven中默认配有一个全球唯一的Maven仓库地址，该地址的配置文件是在Maven根目录下的lib文件夹下的“maven-model-builder-3.3.3.jar”中。在该jar包中的“maven-model-builder3.3.3.jar\org\apache\maven\model”
下的“pom-4.0.0.xml”中，如下：

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

Maven中央仓库地址：

  其中Maven中央仓库的地址为“https://repo.maven.apache.org/maven2”在该地址中，我们可以找到绝大多数的开源java项目，基本上平时我们所使用的开源程序框架，在这里都能找到。

3、Maven的镜像仓库

修改镜像仓库地址位置：

  修改文件在maven根目录+“conf/”+“settings.xml”在该配置文件中提供了一个被注释的示例，如下：

<mirror>
      <id>mirrorId</id>
      <mirrorOf>repositoryId</mirrorOf>
      <name>Human Readable Name for this Mirror.</name>
      <url>http://my.repository.com/repo/path</url>
    </mirror>

修改后的镜像

  这里我们采用的是国内的阿里云镜像仓库地址，链接如下：

<mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
  　　<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>        
    </mirror>

  当然我们也可以采用其他的镜像仓库地址，举例说比如说下面的：

<mirror>
      <id>maven.net.cn</id>
      <mirrorOf>central</mirrorOf>
      <name>central mirror in china</name>
      <url>http://maven.net.cn/content/groups/public</url>
</mirror>

  我们一旦配置了镜像仓库，原来要访问原仓库的访问都会转到镜像仓库，原仓库将不能被访问。

4、修改Maven的本地仓库

  在默认的情况下，Maven在加载依赖项时会将远程Maven仓库中的jar等文件下载到本地的操作系统用户根目录下的.m2文件中，比如说我的操作系统位Windows10，我的系统注册用户为HP，那么我的本地Maven默认仓库地址就是为：

C:\Users\HP\.m2

  但是我们知道，随着Maven的不断使用，仓库会越来越大，甚至有可能达到上G的占用空间，由于平均每个依赖文件的大小不足1M，所以说其中加载的文件数量是非常庞大的，而这势必会降低电脑的文件检索速度，由于Maven的默认仓库地址是存放到C盘也就是操作系统存放盘目录中的，因而它可能会严重影响电脑的操作体验，所以说我们通常情况下都不选择Maven的默认本地仓库存放位置，通常情况下我们会将其转移到其它的盘符中。

  Maven修改本地仓库地址的位置和添加Maven镜像仓库的位置一样，所以说直接上结果，比如说我想将仓库转移到E:\Dev\libs\apache-maven-3.3.3文件夹下，我的做法是在settings.xml文件中添加下面的信息。

<localRepository>E:\Dev\libs\apache-maven-3.3.3\repository</localRepository>