Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Maven-Pakete von Upstreams und externen Verbindungen anfordern
Import von Standard-Asset-Namen
Beim Import einer Maven-Paketversion aus einem öffentlichen Repository wie Maven Central CodeArtifact versucht AWS, alle Assets in dieser Paketversion zu importieren. Wie unter beschriebenEine Paketversion mit Upstream-Repositorys anfordern, erfolgt der Import in den folgenden Fällen:
-
Ein Client fordert ein Maven-Asset aus einem CodeArtifact Repository an.
-
Die Paketversion ist noch nicht im Repository oder seinen Upstreams vorhanden.
-
Es gibt eine erreichbare externe Verbindung zu einem öffentlichen Maven-Repository.
Auch wenn der Client möglicherweise nur ein Asset angefordert hat, CodeArtifact versucht er, alle Assets zu importieren, die er für diese Paketversion finden kann. Wie CodeArtifact festgestellt wird, welche Ressourcen für eine Maven-Paketversion verfügbar sind, hängt vom jeweiligen öffentlichen Repository ab. Einige öffentliche Maven-Repositorien unterstützen das Anfordern einer Liste von Assets, andere jedoch nicht. CodeArtifact Generiert für Repositorys, die keine Möglichkeit bieten, Assets aufzulisten, eine Reihe von Asset-Namen, die wahrscheinlich existieren. Wenn beispielsweise ein Asset der Maven-Paketversion junit 4.13.2 angefordert CodeArtifact wird, wird versucht, die folgenden Assets zu importieren:
junit-4.13.2.pomjunit-4.13.2.jarjunit-4.13.2-javadoc.jarjunit-4.13.2-sources.jar
Importieren von nicht standardmäßigen Asset-Namen
Wenn ein Maven-Client ein Asset anfordert, das keinem der oben beschriebenen Muster entspricht, wird CodeArtifact geprüft, ob dieses Asset im öffentlichen Repository vorhanden ist. Wenn das Asset vorhanden ist, wird es importiert und dem vorhandenen Paketversionsdatensatz hinzugefügt, falls einer existiert. Die Maven-Paketversion com.android.tools.build:aapt2
7.3.1-8691043 enthält beispielsweise die folgenden Ressourcen:
aapt2-7.3.1-8691043.pomaapt2-7.3.1-8691043-windows.jaraapt2-7.3.1-8691043-osx.jaraapt2-7.3.1-8691043-linux.jar
Wenn ein Client die POM-Datei anfordert und die Ressourcen der Paketversion nicht auflisten kann, ist das POM das einzige importierte Asset. CodeArtifact Dies liegt daran, dass keines der anderen Assets den Standardmustern für Asset-Namen entspricht. Wenn der Client jedoch eines der JAR-Assets anfordert, wird dieses Asset importiert und der vorhandenen Paketversion hinzugefügt, in der gespeichert ist CodeArtifact. Die Paketversionen sowohl im am weitesten nachgelagerten Repository (dem Repository, für das der Client die Anfrage gestellt hat) als auch im Repository, an das die externe Verbindung angeschlossen ist, werden aktualisiert, sodass sie das neue Asset enthalten, wie unter beschrieben. Aufbewahrung von Paketen aus Upstream-Repositorys
Sobald eine Paketversion in einem CodeArtifact Repository gespeichert ist, ist sie normalerweise nicht von Änderungen in den Upstream-Repositorys betroffen. Weitere Informationen finden Sie unter Aufbewahrung von Paketen aus Upstream-Repositorys. Das zuvor beschriebene Verhalten von Maven-Assets mit nicht standardmäßigen Namen stellt jedoch eine Ausnahme von dieser Regel dar. Die Downstream-Paketversion ändert sich zwar nicht, ohne dass ein zusätzlicher Inhalt von einem Client angefordert wird, aber in diesem Fall wird die beibehaltene Paketversion geändert, nachdem sie ursprünglich beibehalten wurde, und ist daher nicht unveränderlich. Dieses Verhalten ist notwendig, da Maven-Assets mit nicht standardmäßigen Namen andernfalls nicht zugänglich wären. CodeArtifact Dieses Verhalten ist auch möglich, wenn sie zu einer Maven-Paketversion in einem öffentlichen Repository hinzugefügt werden, nachdem die Paketversion in einem Repository aufbewahrt wurde. CodeArtifact
Die Herkunft von Assets wird überprüft
Wenn Sie einer zuvor beibehaltenen Maven-Paketversion ein neues Asset hinzufügen, wird CodeArtifact bestätigt, dass der Ursprung der beibehaltenen Paketversion mit dem Ursprung des neuen Assets identisch ist. Dadurch wird verhindert, dass eine „gemischte“ Paketversion erstellt wird, bei der verschiedene Assets aus unterschiedlichen öffentlichen Repositorys stammen. Ohne diese Prüfung könnte es zu einer Vermischung von Assets kommen, wenn eine Maven-Paketversion in mehr als einem öffentlichen Repository veröffentlicht wird und diese Repositorys Teil des Upstream-Graphen eines CodeArtifact Repositorys sind.
Import neuer Assets und Paketversionsstatus in Upstream-Repositorys
Der Paketversionsstatus von Paketversionen in Upstream-Repositorys kann CodeArtifact verhindern, dass diese Versionen in Downstream-Repositorys beibehalten werden.
Nehmen wir zum Beispiel an, eine Domain hat drei Repositorys:repo-A,, und repo-Brepo-C, wobei repo-B sich ein Upstream von repo-A und repo-C ein Upstream von befinden. repo-B
Die Paketversion 7.3.1 des Maven-Pakets com.android.tools.build:aapt2 ist in vorhanden repo-B und hat den Status. Published Es ist nicht vorhanden inrepo-A. Wenn ein Client ein Asset dieser Paketversion anfordertrepo-A, lautet die Antwort 200 (OK) und die Maven-Paketversion 7.3.1 wird beibehalten. repo-A Wenn der Status der Paketversion 7.3.1 in jedoch Archived oder repo-B lautetDisposed, lautet die Antwort 404 (Not Found), da die Ressourcen der Paketversionen in diesen beiden Status nicht heruntergeladen werden können.
Beachten Sie, dass das Setzen der Paketquellkontrolle auf upstream=BLOCK for com.android.tools.build:aapt2 in repo-Arepo-B, und repo-C verhindert, dass neue Inhalte für alle Versionen dieses Pakets abgerufen werdenrepo-A, unabhängig vom Status der Paketversion.
