Maven从仓库解析并使用依赖构建的机制。

当本地仓库没有依赖构件的时候，Maven会自动从远程仓库下载；当依赖版本为快照版本的时候，Maven会自动找到最新的快照。这背后的依赖解析机制可以概括如下：

当依赖的范围是system的时候，Maven直接从本地文件系统解析构件。
根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功。
在本地仓库不存在相应构件的情况下，如果依赖的版本是RELEASE或者LATEST，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/maven-metadata.xml，将其与本地仓库的对应元数据合并后，计算出RELEASE或者LATEST真实的值，然后基于这个真实的值检查本地和远程仓库，如步骤2和3。
如果依赖的版本是SNAPSHOT，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml，将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该值检查本地仓库，或者从远程仓库下载。
如果最后解析得到的构建版本是时间戳格式的快照，如1.4.1-20091104.121450-121，则复制其时间戳格式的文件至非时间戳格式，如SNAPSHOT，并使用该非时间戳格式的构件。

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

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

回顾一下前面提到的RELEASE和LATEST版本，他们分别对应了仓库中存在的该构件的最新发布版本和最新版本（包含快照），而这两个“最新”是基于groupId/artifactId/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不会明确告诉用户这样的变化。当这种变化造成构件失败的时候，发现问题会变得比较困难。RELEASE因为对应的是最新发布版构件，还相对可靠，LATEST就非常不可靠了，为此，Maven3不再支持在插件配置中使用LATEST和RELEASE。如果不设置插件版本，其效果就和RELEASE一样，Maven只会解析最新发布版本构件。不过即使这样，也还存在前在的问题。例如，某个依赖的1.1版本与1.2版本可能发生一些接口的变化，从而导致当前Maven构件的失败。

当依赖的版本设为快照版本的时候，Maven也需要检查更新，这时，Maven会检查仓库元数据groupId/artifactId/version/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元素包含了timpestamp和buildNumber两个子元素，分别代表了这一快照的时间戳和构件号，基于这两个元素可以得到该仓库中此快照的最新构件版本实际为1.4.2-20091214.221414-13。通过合并所有远程仓库和本地仓库的元数据，Maven就能知道所有仓库中该构件的最新快照。

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

Maven从仓库解析并使用依赖构建的机制。

猜你喜欢