本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 从上游和外部连接请求 Maven 程序包
<a name="maven-upstream-external-connections-request"></a>



## 导入标准资产名称
<a name="maven-import-standard-asset-names"></a>

从公共存储库（例如 Maven Central）导入 Maven 包版本时，AWS CodeArtifact 会尝试导入该软件包版本中的所有资产。如 [请求包含上游存储库的程序包版本](repo-upstream-behavior.md) 中所述，在以下时候会发生导入：
+ 客户端向 CodeArtifact 存储库请求 Maven 资产。
+ 程序包版本尚未出现在存储库或其上游中。
+ 存在与公有 Maven 存储库的可访问外部连接。

尽管客户端可能只请求了一个资产，但仍会 CodeArtifact 尝试导入它能找到的适用于该软件包版本的所有资产。如何 CodeArtifact 发现哪些资产可用于 Maven 软件包版本取决于特定的公共存储库。一些公有 Maven 存储库支持请求资产列表，但其他存储库则不支持。对于不提供列出资产的方式的存储库， CodeArtifact 会生成一组可能存在的资产名称。例如，当请求任何 Maven 包版本的资源`junit 4.13.2`时， CodeArtifact 将尝试导入以下资产：
+ `junit-4.13.2.pom`
+ `junit-4.13.2.jar`
+ `junit-4.13.2-javadoc.jar`
+ `junit-4.13.2-sources.jar`

## 导入非标准资产名称
<a name="maven-import-nonstandard-asset-names"></a>

当 Maven 客户端请求的资产与上述模式不匹配时， CodeArtifact 会检查该资产是否存在于公共存储库中。如果存在资产，则会将其导入并添加到现有的程序包版本记录（如果存在）中。例如，Maven 程序包版本 `com.android.tools.build:aapt2 7.3.1-8691043` 包含以下资产：
+ `aapt2-7.3.1-8691043.pom`
+ `aapt2-7.3.1-8691043-windows.jar`
+ `aapt2-7.3.1-8691043-osx.jar`
+ `aapt2-7.3.1-8691043-linux.jar`

当客户请求 POM 文件时，如果无法列出软件包版本的资产，则 POM 将 CodeArtifact 是唯一导入的资产。这是因为其他资产都不符合标准资产名称模式。但是，当客户端请求其中一个 JAR 资产时，该资产将被导入并添加到存储在中的现有软件包版本中 CodeArtifact。最下游存储库（客户端向其发出请求的存储库）和具有外部连接的存储库中的程序包版本都将更新为包含新资产，如[上游存储库的程序包保留](repo-upstream-behavior.md#package-retention-upstream-repos)中所述。

通常，软件包版本一旦保留在 CodeArtifact 存储库中，就不会受到上游存储库中更改的影响。有关更多信息，请参阅 [上游存储库的程序包保留](repo-upstream-behavior.md#package-retention-upstream-repos)。但是，对于具有前面所述的非标准名称的 Maven 资产，其行为与此规则不同。虽然如果客户端没有请求额外的资产，下游程序包版本就不会更改，但在这种情况下，保留的程序包版本在最初保留后经过修改，因此不是一成不变的。这种行为是必要的，因为否则将无法通过 CodeArtifact访问具有非标准名称的 Maven 资产。如果将软件包版本保留在存储库中之后，将其添加到公共存储库上的 Maven 软件包版本中，则该行为也会启用。 CodeArtifact 

## 检查资产来源
<a name="origin-checks-for-assets"></a>

将新资源添加到先前保留的 Maven 软件包版本时， CodeArtifact 确认保留的软件包版本的来源与新资产的来源相同。这可以防止创建“混合”程序包版本，其中不同的资产来自不同的公有存储库。如果不进行此检查，则如果将 Maven 包版本发布到多个公共存储库，并且这些存储库是存储库上游图的一部分，则可能会发生资产混合。 CodeArtifact 

## 在上游存储库中导入新资产和程序包版本状态
<a name="new-asset-importing-pv-status-upstream-repos"></a>

上游存储库中软件包版本的软件包版本[状态](packages-overview.md#package-version-status)可能会 CodeArtifact 阻止在下游存储库中保留这些版本。

例如，假设一个域有三个存储库：`repo-A`、`repo-B` 和 `repo-C`，其中 `repo-B` 是 `repo-A` 的上游存储库，`repo-C` 是 `repo-B` 的下游存储库。

![\[上游存储库中新资产和程序包版本的工作原理示意图。\]](http://docs.aws.amazon.com/zh_cn/codeartifact/latest/ug/images/Maven-new-asset-pv-upstream.png)


`repo-B` 中存在 Maven 程序包 `com.android.tools.build:aapt2` 的程序包版本 `7.3.1`，其状态为 `Published`。它不存在于 `repo-A` 中。如果客户端从 `repo-A` 请求此程序包版本的资产，则响应将为 200（正常），且 Maven 程序包版本 `7.3.1` 将保留在 `repo-A` 中。但是，如果 `repo-B` 中的程序包版本 `7.3.1` 的状态为 `Archived` 或 `Disposed`，则响应将为 404（未找到），因为处于这两种状态的程序包版本的资产不可下载。

请注意，为 `repo-A`、`repo-B` 和 `repo-C` 中的 `com.android.tools.build:aapt2` 将[程序包来源控制](package-origin-controls.md)设置为 `upstream=BLOCK`，则无论程序包的版本状态是什么，都可防止从 `repo-A` 为该程序包的所有版本提取新资产。