Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Demande de packages Maven depuis des connexions en amont et externes

Importation de noms d'actifs standard

Lors de l'importation d'une version de package Maven depuis un référentiel public, tel que Maven Central, AWS CodeArtifact tente d'importer toutes les ressources de cette version de package. Comme décrit dansDemande d'une version de package avec des référentiels en amont, l'importation a lieu lorsque :

Même si le client n'a demandé qu'une seule ressource, il CodeArtifact tente d'importer toutes les ressources qu'il trouve pour cette version de package. La CodeArtifact manière de découvrir quels actifs sont disponibles pour une version de package Maven dépend du référentiel public concerné. Certains référentiels Maven publics permettent de demander une liste d'actifs, mais d'autres ne le font pas. Pour les référentiels qui ne permettent pas de répertorier les actifs, CodeArtifact génère un ensemble de noms d'actifs susceptibles d'exister. Par exemple, lorsqu'un actif de la version du package Maven junit 4.13.2 est demandé, CodeArtifact il tente d'importer les actifs suivants :

Importation de noms d'actifs non standard

Lorsqu'un client Maven demande un actif qui ne correspond pas à l'un des modèles décrits ci-dessus, CodeArtifact vérifie si cet actif est présent dans le référentiel public. Si la ressource est présente, elle sera importée et ajoutée à l'enregistrement de version du package existant, le cas échéant. Par exemple, la version du package Maven com.android.tools.build:aapt2 7.3.1-8691043 contient les actifs suivants :

Lorsqu'un client demande le fichier POM, s'il n' CodeArtifact est pas en mesure de répertorier les actifs de la version du package, le POM sera le seul actif importé. Cela est dû au fait qu'aucun des autres actifs ne correspond aux modèles de noms d'actifs standard. Toutefois, lorsque le client demande l'une des ressources JAR, cette ressource est importée et ajoutée à la version du package existante stockée dans CodeArtifact. Les versions du package du référentiel le plus en aval (le référentiel contre lequel le client a fait la demande) et du référentiel associé à la connexion externe seront mises à jour pour contenir le nouvel actif, comme décrit dans. Conservation des packages depuis les référentiels en amont

Normalement, une fois qu'une version de package est conservée dans un CodeArtifact référentiel, elle n'est pas affectée par les modifications apportées aux référentiels en amont. Pour plus d’informations, consultez Conservation des packages depuis les référentiels en amont. Cependant, le comportement des actifs Maven avec des noms non standard décrit précédemment constitue une exception à cette règle. Bien que la version du package en aval ne change pas sans qu'un actif supplémentaire ne soit demandé par un client, dans ce cas, la version du package conservée est modifiée après avoir été initialement conservée et n'est donc pas immuable. Ce comportement est nécessaire car les actifs Maven portant des noms non standard ne seraient autrement pas accessibles via. CodeArtifact Ce comportement est également activé s'ils sont ajoutés à une version de package Maven sur un référentiel public une fois que la version du package a été conservée dans un CodeArtifact référentiel.

Vérifier l'origine des actifs

Lorsque vous ajoutez un nouvel actif à une version de package Maven précédemment conservée, vous CodeArtifact confirmez que l'origine de la version de package conservée est la même que celle du nouvel actif. Cela empêche de créer une version de package « mixte » dans laquelle différents actifs proviennent de différents référentiels publics. Sans cette vérification, un mélange d'actifs peut se produire si une version de package Maven est publiée dans plusieurs référentiels publics et que ces référentiels font partie du graphe en amont d'un CodeArtifact référentiel.

Importation de nouveaux actifs et de l'état de la version du package dans les référentiels en amont

L'état des versions de package des versions de package dans les référentiels en amont peut CodeArtifact empêcher de conserver ces versions dans les référentiels en aval.

Par exemple, supposons qu'un domaine possède trois référentiels :repo-A,repo-B, etrepo-C, où se repo-B trouve en amont repo-A et repo-C en amont de. repo-B

La version 7.3.1 du package Maven com.android.tools.build:aapt2 est présente dans repo-B et a un statut dePublished. Il n'est pas présent dansrepo-A. Si un client demande un actif de cette version de packagerepo-A, la réponse sera 200 (OK) et la version du package Maven 7.3.1 sera conservéerepo-A. Toutefois, si le statut de la version 7.3.1 du package repo-B est Archived ouDisposed, la réponse sera 404 (Introuvable) car les actifs des versions du package correspondant à ces deux statuts ne sont pas téléchargeables.

Notez que le fait de définir le contrôle d'origine du package sur upstream=BLOCK for com.android.tools.build:aapt2 in repo-Arepo-B, et repo-C empêchera la récupération de nouveaux actifs pour toutes les versions de ce packagerepo-A, quel que soit le statut de la version du package.