从上游和外部连接请求 Maven 程序包

导入标准资产名称

从公有存储库（例如 Maven Central）导入 Maven 程序包版本时，AWS CodeArtifact 会尝试导入该程序包版本中的所有资产。如 请求包含上游存储库的程序包版本 中所述，在以下时候会发生导入：

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

导入非标准资产名称

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

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

通常，在 CodeArtifact 存储库中保留程序包版本之后，它就不会受到上游存储库中更改的影响。有关更多信息，请参阅 上游存储库的程序包保留。但是，对于具有前面所述的非标准名称的 Maven 资产，其行为与此规则不同。虽然如果客户端没有请求额外的资产，下游程序包版本就不会更改，但在这种情况下，保留的程序包版本在最初保留后经过修改，因此不是一成不变的。由于具有非标准名称的 Maven 资产在没有特殊处理的情况下无法通过 CodeArtifact 访问，所以需要这种特殊的行为。如果在 CodeArtifact 存储库中保留程序包版本之后，对公有存储库的 Maven 程序包版本添加这种行为，则该行为也会起作用。

检查资产来源

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

在上游存储库中导入新资产和程序包版本状态

上游存储库中程序包版本的程序包版本状态会阻止 CodeArtifact 将这些版本保留在下游存储库中。

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

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 将程序包来源控制设置为 upstream=BLOCK，则无论程序包的版本状态是什么，都可防止从 repo-A 为该程序包的所有版本提取新资产。