Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo CodeArtifact con Maven
Il formato di repository Maven è utilizzato da molti linguaggi diversi, tra cui Java, Kotlin, Scala e Clojure. È supportato da molti strumenti di compilazione diversi, tra cui Maven, Gradle, Scala SBT, Apache Ivy e Leiningen.
Abbiamo testato e confermato la compatibilità con le seguenti versioni: CodeArtifact
+ Ultima versione di **Maven**: 3.6.3.
+ È stata testata anche **l'ultima versione di Gradle**: 6.4.1. La 5.5.1 è stata testata.
+ È stata testata anche l'ultima versione di **Clojure**: 1.11.1.
**Topics**
+ [Uso CodeArtifact con Gradle](maven-gradle.md)
+ [Usare CodeArtifact con mvn](maven-mvn.md)
+ [Utilizzare CodeArtifact con deps.edn](maven-deps.md)
+ [Pubblicazione con curl](maven-curl.md)
+ [Usa i checksum Maven](maven-checksums.md)
+ [Usa le istantanee di Maven](maven-snapshots.md)
+ [Richiesta di pacchetti Maven da upstream e connessioni esterne](maven-upstream-external-connections-request.md)
+ [Risoluzione dei problemi con Maven](maven-troubleshooting.md)
# Uso CodeArtifact con Gradle
Dopo aver inserito il token di CodeArtifact autenticazione in una variabile di ambiente, come descritto in [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var), segui queste istruzioni per utilizzare i pacchetti Maven da e pubblicare nuovi pacchetti in un repository. CodeArtifact
**Topics**
+ [Recupera le dipendenze](#fetching-dependencies)
+ [Recupera i plugin](#fetching-plugins)
+ [Pubblica artefatti](#publishing-artifacts)
+ [Esegui una build Gradle in IntelliJ IDEA](#gradle-intellij)
## Recupera le dipendenze
Per recuperare le dipendenze da CodeArtifact una build Gradle, utilizzate la seguente procedura.
**Per recuperare le dipendenze da una build Gradle CodeArtifact**
1. In caso contrario, crea e archivia un token di CodeArtifact autenticazione in una variabile di ambiente seguendo la procedura in. [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var)
1. Aggiungete una `maven` sezione alla `repositories` sezione del `build.gradle` file di progetto.
```
maven {
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username "aws"
password System.env.CODEARTIFACT_AUTH_TOKEN
}
}
```
L'`url`esempio precedente è l'endpoint del tuo CodeArtifact repository. Gradle utilizza l'endpoint per connettersi al tuo repository. Nell'esempio, `my_domain` è il nome del tuo dominio, `111122223333` è l'ID del proprietario del dominio ed `my_repo` è il nome del tuo repository. È possibile recuperare l'endpoint di un repository utilizzando il comando. `get-repository-endpoint` AWS CLI
Ad esempio, con un repository denominato *my\$1repo* all'interno di un dominio denominato*my\$1domain*, il comando è il seguente:
```
aws codeartifact get-repository-endpoint --domain my_domain --domain-owner 111122223333 --repository my_repo --format maven
```
Il `get-repository-endpoint` comando restituirà l'endpoint del repository:
```
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
```
L'`credentials`oggetto nell'esempio precedente include il token di CodeArtifact autenticazione creato nel passaggio 1 che Gradle utilizza per l'autenticazione. CodeArtifact
**Nota**
Per utilizzare un endpoint dualstack, usa l'endpoint. `codeartifact.region.on.aws`
1. (Facoltativo): per utilizzare il CodeArtifact repository come unica fonte per le dipendenze del progetto, rimuovi tutte le altre sezioni in from. `repositories` `build.gradle` Se hai più di un repository, Gradle cerca in ogni repository le dipendenze nell'ordine in cui sono elencate.
1. Dopo aver configurato il repository, puoi aggiungere le dipendenze del progetto alla sezione con la sintassi Gradle standard. `dependencies`
```
dependencies {
implementation 'com.google.guava:guava:27.1-jre'
implementation 'commons-cli:commons-cli:1.4'
testImplementation 'org.testng:testng:6.14.3'
}
```
## Recupera i plugin
[Per impostazione predefinita, Gradle risolverà i plugin dal Gradle Plugin Portal pubblico.](https://plugins.gradle.org/) Per estrarre i plugin da un CodeArtifact repository, utilizzate la seguente procedura.
**Per estrarre i plugin da un repository CodeArtifact**
1. Se non l'hai fatto, crea e archivia un token di CodeArtifact autenticazione in una variabile di ambiente seguendo la procedura in. [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var)
1. Aggiungi un `pluginManagement` blocco al tuo `settings.gradle` file. Il `pluginManagement` blocco deve apparire prima di qualsiasi altra istruzione`settings.gradle`, vedi il seguente frammento:
```
pluginManagement {
repositories {
maven {
name 'my_repo'
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username 'aws'
password System.env.CODEARTIFACT_AUTH_TOKEN
}
}
}
}
```
Ciò assicurerà che Gradle risolva i plugin dal repository specificato. Il repository deve avere un repository upstream con una connessione esterna al Gradle Plugin Portal (ad esempio`gradle-plugins-store`) in modo che i plugin Gradle comunemente richiesti siano disponibili per la build. [Per ulteriori informazioni, consultate la documentazione di Gradle.](https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories)
## Pubblica artefatti
Questa sezione descrive come pubblicare una libreria Java creata con Gradle in un repository. CodeArtifact
Innanzitutto, aggiungi il `maven-publish` plugin alla `plugins` sezione del file del `build.gradle` progetto.
```
plugins {
id 'java-library'
id 'maven-publish'
}
```
Quindi, aggiungi una `publishing` sezione al `build.gradle` file di progetto.
```
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'group-id'
artifactId = 'artifact-id'
version = 'version'
from components.java
}
}
repositories {
maven {
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username "aws"
password System.env.CODEARTIFACT_AUTH_TOKEN
}
}
}
}
```
Il `maven-publish` plugin genera un file POM basato su `groupId``artifactId`, e `version` specificato nella `publishing` sezione.
Una volta `build.gradle` completate queste modifiche, esegui il comando seguente per creare il progetto e caricarlo nel repository.
```
./gradlew publish
```
`list-package-versions`Utilizzatelo per verificare che il pacchetto sia stato pubblicato correttamente.
```
aws codeartifact list-package-versions --domain my_domain --domain-owner 111122223333 --repository my_repo --format maven\
--namespace com.company.framework --package my-package-name
```
Output di esempio:
```
{
"format": "maven",
"namespace": "com.company.framework",
"package": "example",
"versions": [
{
"version": "1.0",
"revision": "REVISION-SAMPLE-1-C7F4S5E9B772FC",
"status": "Published"
}
]
}
```
Per ulteriori informazioni, consulta questi argomenti sul sito Web di Gradle:
+ [Creazione di librerie Java](https://guides.gradle.org/building-java-libraries/)
+ [Pubblicazione di un progetto come modulo](https://docs.gradle.org/current/userguide/publishing_setup.html)
## Esegui una build Gradle in IntelliJ IDEA
È possibile eseguire una build Gradle in IntelliJ IDEA da cui estrae le dipendenze. CodeArtifact Per eseguire l'autenticazione CodeArtifact, è necessario fornire a Gradle un token di autorizzazione. CodeArtifact Esistono tre metodi per fornire un token di autenticazione.
+ Metodo 1: memorizzazione del token di autenticazione in. `gradle.properties` Utilizzate questo metodo se siete in grado di sovrascrivere o aggiungere elementi al contenuto del `gradle.properties` file.
+ Metodo 2: memorizzazione del token di autenticazione in un file separato. Utilizzate questo metodo se non desiderate modificare il `gradle.properties` file.
+ Metodo 3: generazione di un nuovo token di autenticazione per ogni esecuzione eseguendolo `aws` come script in linea in. `build.gradle` Usa questo metodo se vuoi che lo script Gradle recuperi un nuovo token ad ogni esecuzione. Il token non verrà archiviato nel file system.
------
#### [ Token stored in gradle.properties ]
**Metodo 1: memorizzazione del token di autenticazione in `gradle.properties`**
**Nota**
L'esempio mostra il `gradle.properties` file che si trova in`GRADLE_USER_HOME`.
1. Aggiorna il `build.gradle` file con il seguente frammento:
```
repositories {
maven {
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username "aws"
password "$codeartifactToken"
}
}
}
```
1. Per recuperare i plugin CodeArtifact, aggiungi un `pluginManagement` blocco al tuo file. `settings.gradle` Il `pluginManagement` blocco deve apparire prima di qualsiasi altra istruzione in. `settings.gradle`
```
pluginManagement {
repositories {
maven {
name 'my_repo'
url 'https://my_domain-111122223333.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username 'aws'
password "$codeartifactToken"
}
}
}
}
```
1. Recupera un token di CodeArtifact autenticazione:
```
export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain my_domain --domain-owner 111122223333 --query authorizationToken --output text --profile profile-name`
```
1. Scrivi il token di autenticazione nel file: `gradle.properties`
```
echo "codeartifactToken=$CODEARTIFACT_AUTH_TOKEN" > ~/.gradle/gradle.properties
```
------
#### [ Token stored in separate file ]
**Metodo 2: memorizzazione del token di autenticazione in un file separato**
1. Aggiorna il `build.gradle` file con il seguente frammento:
```
def props = new Properties()
file("file").withInputStream { props.load(it) }
repositories {
maven {
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username "aws"
password props.getProperty("codeartifactToken")
}
}
}
```
1. Per recuperare i plugin CodeArtifact, aggiungi un `pluginManagement` blocco al tuo file. `settings.gradle` Il `pluginManagement` blocco deve apparire prima di qualsiasi altra istruzione in. `settings.gradle`
```
pluginManagement {
def props = new Properties()
file("file").withInputStream { props.load(it) }
repositories {
maven {
name 'my_repo'
url 'https://my_domain-111122223333.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username 'aws'
password props.getProperty("codeartifactToken")
}
}
}
}
```
1. Recupera un token di CodeArtifact autenticazione:
```
export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain my_domain --domain-owner 111122223333 --query authorizationToken --output text --profile profile-name`
```
1. Scrivi il token di autenticazione nel file specificato nel tuo file: `build.gradle`
```
echo "codeartifactToken=$CODEARTIFACT_AUTH_TOKEN" > file
```
------
#### [ Token generated for each run in build.gradle ]
**Metodo 3: generazione di un nuovo token di autenticazione per ogni esecuzione eseguendolo `aws` come script in linea in `build.gradle`**
1. Aggiorna il `build.gradle` file con il seguente frammento:
```
def codeartifactToken = "aws codeartifact get-authorization-token --domain my_domain --domain-owner 111122223333 --query authorizationToken --output text --profile profile-name".execute().text
repositories {
maven {
url 'https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username "aws"
password codeartifactToken
}
}
}
```
1. Per recuperare i plugin CodeArtifact, aggiungi un `pluginManagement` blocco al tuo file. `settings.gradle` Il `pluginManagement` blocco deve apparire prima di qualsiasi altra istruzione in. `settings.gradle`
```
pluginManagement {
def codeartifactToken = "aws codeartifact get-authorization-token --domain my_domain --domain-owner 111122223333 --query authorizationToken --output text --profile profile-name".execute().text
repositories {
maven {
name 'my_repo'
url 'https://my_domain-111122223333.codeartifact.region.amazonaws.com/maven/my_repo/'
credentials {
username 'aws'
password codeartifactToken
}
}
}
}
```
------
# Usare CodeArtifact con mvn
Si usa il `mvn` comando per eseguire le build di Maven. Questa sezione mostra come configurare l'uso di un `mvn` repository. CodeArtifact
**Topics**
+ [Recupera le dipendenze](#fetching-dependencies)
+ [Pubblica artefatti](#publishing-artifacts)
+ [Pubblica artefatti di terze parti](#publishing-third-party-artifacts)
+ [Limita i download delle dipendenze di Maven a un repository CodeArtifact](#restrict-maven-downloads)
+ [Informazioni sul progetto Apache Maven](#apache-maven-project-info)
## Recupera le dipendenze
`mvn`Per configurare il recupero delle dipendenze da un CodeArtifact repository, devi modificare il file di configurazione di Maven e, facoltativamente`settings.xml`, il POM del tuo progetto.
1. Se non l'hai fatto, crea e archivia un token di CodeArtifact autenticazione in una variabile di ambiente come descritto in per configurare l'autenticazione nel [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var) tuo repository. CodeArtifact
1. In `settings.xml` (in genere si trova in`~/.m2/settings.xml`), aggiungi una `` sezione con un riferimento alla variabile di `CODEARTIFACT_AUTH_TOKEN` ambiente in modo che Maven passi il token nelle richieste HTTP.
```
...
codeartifact
aws
${env.CODEARTIFACT_AUTH_TOKEN}
...
```
1. Aggiungi l'endpoint URL per il tuo CodeArtifact repository in un elemento. `` Puoi farlo nel file `settings.xml` POM del tuo progetto.
Puoi recuperare l'endpoint del tuo repository usando il comando. `get-repository-endpoint` AWS CLI
Ad esempio, con un repository denominato *my\$1repo* all'interno di un dominio denominato*my\$1domain*, il comando è il seguente:
```
aws codeartifact get-repository-endpoint --domain my_domain --repository my_repo --format maven
```
Il `get-repository-endpoint` comando restituirà l'endpoint del repository:
```
url 'https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/'
```
**Nota**
Per utilizzare un endpoint dualstack, usa l'endpoint. `codeartifact.region.on.aws`
Aggiungi l'endpoint del repository come segue. `settings.xml`
```
...
default
codeartifact
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/
default
...
```
In alternativa, è possibile aggiungere la `` sezione a un file POM di progetto da utilizzare solo CodeArtifact per quel progetto.
```
...
codeartifact
codeartifact
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/
...
```
**Importante**
È possibile utilizzare qualsiasi valore nell'``elemento, ma deve essere lo stesso in entrambi `` gli `` elementi. Ciò consente di includere le credenziali specificate nelle richieste di CodeArtifact.
Dopo aver apportato queste modifiche alla configurazione, puoi creare il progetto.
```
mvn compile
```
Maven registra l'URL completo di tutte le dipendenze scaricate sulla console.
```
[INFO] ------------------< com.example.example:myapp >-------------------
[INFO] Building myapp 1.0
[INFO] --------------------------------[ jar ]---------------------------------
Downloading from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
Downloaded from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/commons-cli/commons-cli/1.4/commons-cli-1.4.pom (11 kB at 3.9 kB/s)
Downloading from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/org/apache/commons/commons-parent/42/commons-parent-42.pom
Downloading from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/org/apache/commons/commons-parent/42/commons-parent-42.pom
Downloaded from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/org/apache/commons/commons-parent/42/commons-parent-42.pom (68 kB at 123 kB/s)
Downloading from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
Downloaded from codeartifact: https://.d.codeartifact.us-west-2.amazonaws.com/maven/myrepo/commons-cli/commons-cli/1.4/commons-cli-1.4.jar (54 kB at 134 kB/s)
```
## Pubblica artefatti
Per pubblicare un artefatto Maven in un CodeArtifact repository, devi anche modificare e progettare POM. `mvn` `~/.m2/settings.xml`
1. Se non l'hai fatto, crea e archivia un token di CodeArtifact autenticazione in una variabile di ambiente come descritto in [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var) per configurare l'autenticazione nel tuo repository. CodeArtifact
1. Aggiungi una `` sezione a `settings.xml` con un riferimento alla variabile di `CODEARTIFACT_AUTH_TOKEN` ambiente in modo che Maven passi il token nelle richieste HTTP.
```
...
codeartifact
aws
${env.CODEARTIFACT_AUTH_TOKEN}
...
```
1. Aggiungi una `` sezione a quella del tuo progetto. `pom.xml`
```
...
codeartifact
codeartifact
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/
...
```
Dopo aver apportato queste modifiche alla configurazione, puoi creare il progetto e pubblicarlo nel repository specificato.
```
mvn deploy
```
`list-package-versions`Utilizzatelo per verificare che il pacchetto sia stato pubblicato correttamente.
```
aws codeartifact list-package-versions --domain my_domain --domain-owner 111122223333 --repository my_repo --format maven \
--namespace com.company.framework --package my-package-name
```
Output di esempio:
```
{
"defaultDisplayVersion": null,
"format": "maven",
"namespace": "com.company.framework",
"package": "my-package-name",
"versions": [
{
"version": "1.0",
"revision": "REVISION-SAMPLE-1-C7F4S5E9B772FC",
"status": "Published"
}
]
}
```
## Pubblica artefatti di terze parti
Puoi pubblicare artefatti Maven di terze parti in un repository con. CodeArtifact `mvn deploy:deploy-file` Questo può essere utile per gli utenti che desiderano pubblicare artefatti e dispongono solo di file JAR e non hanno accesso al codice sorgente del pacchetto o ai file POM.
Il `mvn deploy:deploy-file` comando genererà un file POM basato sulle informazioni passate nella riga di comando.
**Pubblica artefatti Maven di terze parti**
1. In caso contrario, crea e archivia un token di CodeArtifact autenticazione in una variabile di ambiente come descritto in [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var) Per configurare l'autenticazione nel tuo repository. CodeArtifact
1. Crea un `~/.m2/settings.xml` file con i seguenti contenuti:
```
codeartifact
aws
${env.CODEARTIFACT_AUTH_TOKEN}
```
1. Eseguire il comando `mvn deploy:deploy-file`:
```
mvn deploy:deploy-file -DgroupId=commons-cli \
-DartifactId=commons-cli \
-Dversion=1.4 \
-Dfile=./commons-cli-1.4.jar \
-Dpackaging=jar \
-DrepositoryId=codeartifact \
-Durl=https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/repo-name/
```
**Nota**
L'esempio precedente pubblica`commons-cli 1.4`. Modifica gli argomenti GroupiD, artifactID, version e file per pubblicare un JAR diverso.
*Queste istruzioni si basano su esempi contenuti nella [Guida alla distribuzione di terze parti in un repository remoto tratti dalla documentazione di JARs Apache](https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html) Maven.*
## Limita i download delle dipendenze di Maven a un repository CodeArtifact
Se un pacchetto non può essere recuperato da un repository configurato, per impostazione predefinita, il `mvn` comando lo recupera da Maven Central. Aggiungi l'`mirrors`elemento a per utilizzare sempre il tuo `settings.xml` repository. `mvn` CodeArtifact
```
...
central-mirror
CodeArtifact Maven Central mirror
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/
central
...
```
Se aggiungi un `mirrors` elemento, devi avere anche un `pluginRepository` elemento nel tuo `settings.xml` or`pom.xml`. L'esempio seguente recupera le dipendenze delle applicazioni e i plugin Maven da un repository. CodeArtifact
```
...
codeartifact
CodeArtifact Plugins
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/
true
true
...
```
L'esempio seguente recupera le dipendenze dell'applicazione da un CodeArtifact repository e recupera i plugin Maven da Maven Central.
```
default
...
central-plugins
Central Plugins
https://repo.maven.apache.org/maven2/
true
true
....
```
## Informazioni sul progetto Apache Maven
Per ulteriori informazioni su Maven, consulta questi argomenti sul sito Web del progetto Apache Maven:
+ [Configurazione di più repository](https://maven.apache.org/guides/mini/guide-multiple-repositories.html)
+ [Riferimento alle impostazioni](https://maven.apache.org/settings.html)
+ [Gestione della distribuzione](https://maven.apache.org/pom.html#Distribution_Management)
+ [Profili](https://maven.apache.org/pom.html#Profiles)
# Utilizzare CodeArtifact con deps.edn
Si utilizza `deps.edn` with `clj` per gestire le dipendenze per i progetti Clojure. Questa sezione mostra come configurare l'uso di un `deps.edn` repository. CodeArtifact
**Topics**
+ [Recupera le dipendenze](#fetching-dependencies-deps)
+ [Pubblica artefatti](#publishing-artifacts-deps)
## Recupera le dipendenze
`Clojure`Per configurare il recupero delle dipendenze da un CodeArtifact repository, è necessario modificare il file di configurazione di Maven,. `settings.xml`
1. Inoltre`settings.xml`, aggiungi una `` sezione con un riferimento alla variabile di `CODEARTIFACT_AUTH_TOKEN` ambiente in modo che Clojure passi il token nelle richieste HTTP.
**Nota**
Clojure si aspetta che il file settings.xml si trovi in. `~/.m2/settings.xml` Se altrove, crea il file in questa posizione.
```
...
codeartifact
aws
${env.CODEARTIFACT_AUTH_TOKEN}
...
```
1. Se non ne hai già uno, genera un file XML POM da utilizzare `clj -Spom` per il tuo progetto.
1. Nel file `deps.edn` di configurazione, aggiungi un repository corrispondente all'id del server di Maven. `settings.xml`
```
:mvn/repos {
"clojars" nil
"central" nil
"codeartifact" {:url "https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/"}
}
```
**Nota**
`tools.deps`garantisce che i `clojars` repository `central` and verranno controllati prima per le librerie Maven. Successivamente, verranno controllati gli altri repository elencati in. `deps.edn`
Per impedire il download diretto da Clojars e Maven Central, `central` è necessario impostarlo su. `clojars` `nil`
Assicurati di avere il token di CodeArtifact autenticazione in una variabile di ambiente (vedi). [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var) Quando si crea il pacchetto dopo queste modifiche, `deps.edn` verranno recuperate le dipendenze in. CodeArtifact
**Nota**
Per utilizzare un endpoint dualstack, usa l'endpoint. `codeartifact.region.on.aws`
## Pubblica artefatti
1. Aggiorna le impostazioni di Maven e includile CodeArtifact come `deps.edn` server riconosciuto da Maven (vedi). [Recupera le dipendenze](#fetching-dependencies-deps) Puoi usare uno strumento come [deps-deploy](https://github.com/slipset/deps-deploy) per caricare artefatti su. CodeArtifact
1. Nel tuo`build.clj`, aggiungi un'`deploy`attività per caricare gli artefatti richiesti nel repository precedentemente configurato. `codeartifact`
```
(ns build
(:require [deps-deploy.deps-deploy :as dd]))
(defn deploy [_]
(dd/deploy {:installer :remote
:artifact "PATH_TO_JAR_FILE.jar"
:pom-file "pom.xml" ;; pom containing artifact coordinates
:repository "codeartifact"}))
```
1. Pubblica l'artefatto eseguendo il comando: `clj -T:build deploy`
Per ulteriori informazioni sulla modifica degli archivi predefiniti, vedere [Modifica dei repository predefiniti nel *Clojure Deps* and CLI](https://clojure.org/reference/deps_and_cli#_modifying_the_default_repositories) Reference Rationale.
# Pubblicazione con curl
Questa sezione mostra come utilizzare il client HTTP per `curl` pubblicare artefatti Maven in un repository. CodeArtifact La pubblicazione di artefatti con `curl` può essere utile se non si dispone o non si desidera installare il client Maven nei propri ambienti.
**Pubblica un artefatto Maven con `curl`**
1. Recupera un token di CodeArtifact autorizzazione seguendo i passaggi indicati [Passa un token di autenticazione utilizzando una variabile di ambiente](tokens-authentication.md#env-var) e torna a questi passaggi.
1. Usa il seguente `curl` comando per pubblicare il JAR in un CodeArtifact repository:
In ciascuno dei `curl` comandi di questa procedura, sostituite i seguenti segnaposto:
+ Sostituiscilo *my\$1domain* con il tuo CodeArtifact nome di dominio.
+ Sostituiscilo *111122223333* con l'ID del proprietario del tuo CodeArtifact dominio.
+ Sostituiscilo *us-west-2* con la regione in cui si trova il tuo CodeArtifact dominio.
+ *my\$1repo*Sostituiscilo con il nome CodeArtifact del tuo repository.
```
curl --request PUT https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/com/mycompany/app/my-app/1.0/my-app-1.0.jar \
--user "aws:$CODEARTIFACT_AUTH_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @my-app-1.0.jar
```
**Importante**
È necessario anteporre un `@` carattere al valore del `--data-binary` parametro. Quando si inserisce il valore tra virgolette, `@` deve essere incluso tra virgolette.
1. Utilizzate il seguente `curl` comando per pubblicare il POM in un repository: CodeArtifact
```
curl --request PUT https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_repo/com/mycompany/app/my-app/1.0/my-app-1.0.pom \
--user "aws:$CODEARTIFACT_AUTH_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @my-app-1.0.pom
```
1. A questo punto, l'artefatto Maven si troverà nel tuo CodeArtifact repository con uno stato di. `Unfinished` Per poter consumare il pacchetto, deve trovarsi nello stato. `Published` Puoi spostare il pacchetto da `Unfinished` a `Published` caricando un `maven-metadata.xml` file sul pacchetto o chiamando l'[UpdatePackageVersionsStatus API](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html) per modificare lo stato.
1. Opzione 1: utilizza il seguente `curl` comando per aggiungere un `maven-metadata.xml` file al pacchetto:
```
curl --request PUT https://my_domain-111122223333.d.codeartifact.region.amazonaws.com/maven/my_repo/com/mycompany/app/my-app/maven-metadata.xml \
--user "aws:$CODEARTIFACT_AUTH_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @maven-metadata.xml
```
Di seguito è riportato un esempio del contenuto di un `maven-metadata.xml` file:
```
com.mycompany.app
my-app
1.0
1.0
1.0
20200731090423
```
1. Opzione 2: aggiorna lo stato del pacchetto `Published` con l'`UpdatePackageVersionsStatus`API.
```
aws codeartifact update-package-versions-status \
--domain my_domain \
--domain-owner 111122223333 \
--repository my_repo \
--format maven \
--namespace com.mycompany.app \
--package my-app \
--versions 1.0 \
--target-status Published
```
Se disponi solo del file JAR di un artefatto, puoi pubblicare una versione del pacchetto consumabile in un CodeArtifact repository utilizzando. `mvn` Questo può essere utile se non avete accesso al codice sorgente o al POM dell'artefatto. Per informazioni dettagliate, vedi [Pubblica artefatti di terze parti](maven-mvn.md#publishing-third-party-artifacts).
# Usa i checksum Maven
Quando un artefatto Maven viene pubblicato in un AWS CodeArtifact repository, il checksum associato a ogni *risorsa* o file del pacchetto viene utilizzato per convalidare il caricamento. **Esempi di risorse sono i file *jar*, pom e war.** Per ogni risorsa, l'artefatto Maven contiene più file di checksum che utilizzano il nome della risorsa con un'estensione aggiuntiva, ad esempio o. `md5` `sha1` Ad esempio, i file di checksum per un file denominato potrebbero essere e. `my-maven-package.jar` `my-maven-package.jar.md5` `my-maven-package.jar.sha1`
**Nota**
Maven usa il termine. `artifact` In questa guida, un pacchetto Maven è uguale a un artefatto Maven. [Per ulteriori informazioni, vedi pacchetto.AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html#welcome-concepts-package)
## Archiviazione con checksum
CodeArtifact non memorizza i checksum di Maven come risorse. [Ciò significa che i checksum non appaiono come singole risorse nell'output dell'API. ListPackageVersionAssets ](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_ListPackageVersionAssets.html) Invece, i checksum calcolati da CodeArtifact sono disponibili per ogni risorsa in tutti i tipi di checksum supportati. Ad esempio, parte della risposta alla chiamata ListPackageVersionAssets sulla versione del pacchetto Maven è: `commons-lang:commons-lang 2.1`
```
{
"name": "commons-lang-2.1.jar",
"size": 207723,
"hashes": {
"MD5": "51591549f1662a64543f08a1d4a0cf87",
"SHA-1": "4763ecc9d78781c915c07eb03e90572c7ff04205",
"SHA-256": "2ded7343dc8e57decd5e6302337139be020fdd885a2935925e8d575975e480b9",
"SHA-512": "a312a5e33b17835f2e82e74ab52ab81f0dec01a7e72a2ba58bb76b6a197ffcd2bb410e341ef7b3720f3b595ce49fdd9994ea887ba08ff6fe21b2c714f8c405af"
}
},
{
"name": "commons-lang-2.1.pom",
"size": 9928,
"hashes": {
"MD5": "8e41bacdd69de9373c20326d231c8a5d",
"SHA-1": "a34d992202615804c534953aba402de55d8ee47c",
"SHA-256": "f1a709cd489f23498a0b6b3dfbfc0d21d4f15904791446dec7f8a58a7da5bd6a",
"SHA-512": "1631ce8fe4101b6cde857f5b1db9b29b937f98ba445a60e76cc2b8f2a732ff24d19b91821a052c1b56b73325104e9280382b2520edda4e7696698165c7e09161"
}
},
{
"name": "maven-metadata.xml",
"size": 121,
"hashes": {
"MD5": "11bb3d48d984f2f49cea1e150b6fa371",
"SHA-1": "7ef872be17357751ce65cb907834b6c5769998db",
"SHA-256": "d04d140362ea8989a824a518439246e7194e719557e8d701831b7f5a8228411c",
"SHA-512": "001813a0333ce4b2a47cf44900470bc2265ae65123a8c6b5ac5f2859184608596baa4d8ee0696d0a497755dade0f6bf5e54667215a06ceae1effdfb7a8d30f88"
}
}
```
Anche se i checksum non sono archiviati come risorse, i client Maven possono comunque pubblicare e scaricare i checksum nelle posizioni previste. Ad esempio, se si `commons-lang:commons-lang 2.1` trovasse in un repository chiamato`maven-repo`, il percorso URL per il checksum SHA-256 del file JAR sarebbe:
```
/maven/maven-repo/commons-lang/commons-lang/2.1/commons-lang-2.1.jar.sha256
```
Se stai caricando pacchetti Maven esistenti (ad esempio, pacchetti precedentemente archiviati in Amazon S3) su un CodeArtifact client HTTP generico, ad esempio`curl`, non è necessario caricare i checksum. CodeArtifact li genererà automaticamente. Se desideri verificare che gli asset siano stati caricati correttamente, puoi utilizzare l'operazione ListPackageVersionAssets API per confrontare i checksum nella risposta con i valori di checksum originali per ogni risorsa.
## I checksum non corrispondono durante la pubblicazione
Oltre agli asset e ai checksum, gli artefatti di Maven contengono anche un file. `maven-metadata.xml` La normale sequenza di pubblicazione per un pacchetto Maven prevede che tutti gli asset e i checksum vengano caricati per primi, seguiti da. `maven-metadata.xml` Ad esempio, la sequenza di pubblicazione per la versione del pacchetto Maven `commons-lang 2.1` descritta in precedenza, presupponendo che il client sia configurato per pubblicare file con checksum SHA-256, sarebbe:
```
PUT commons-lang-2.1.jar
PUT commons-lang-2.1.jar.sha256
PUT commons-lang-2.1.pom
PUT commons-lang-2.1.pom.sha256
PUT maven-metadata.xml
PUT maven-metadata.xml.sha256
```
Quando si carica il file di checksum per una risorsa, ad esempio un file JAR, la richiesta di caricamento del checksum avrà esito negativo e restituirà una risposta **400 (Bad Request)** se c'è una mancata corrispondenza tra il valore del checksum caricato e il valore del checksum calcolato da. CodeArtifact Se la risorsa corrispondente non esiste, la richiesta avrà esito negativo con una risposta **404** (Not Found). Per evitare questo errore, dovete prima caricare la risorsa e poi caricare il checksum.
Quando `maven-metadata.xml` viene caricato, CodeArtifact normalmente cambia lo stato della versione del pacchetto Maven da a. `Unfinished` `Published` Se viene rilevata una mancata corrispondenza del checksum per qualsiasi risorsa, CodeArtifact restituirà un **400 (Bad Request) in risposta alla richiesta** di pubblicazione. `maven-metadata.xml` Questo errore può causare l'interruzione del caricamento dei file per quella versione del pacchetto da parte del client. Se ciò si verifica e il `maven-metadata.xml` file non viene caricato, le risorse della versione del pacchetto già caricate non possono essere scaricate. Questo perché lo stato della versione del pacchetto non è impostato `Published` e rimane invariato`Unfinished`.
CodeArtifact consente di aggiungere ulteriori risorse a una versione del pacchetto Maven anche dopo che `maven-metadata.xml` è stata caricata e lo stato della versione del pacchetto è stato impostato su. `Published` In questo stato, anche una richiesta di caricamento di un file di checksum non corrispondente fallirà con una risposta **400 (**Bad Request). Tuttavia, poiché lo stato della versione del pacchetto è già stato impostato su`Published`, potete scaricare qualsiasi risorsa dal pacchetto, incluse quelle per cui il caricamento del file con il checksum non è riuscito. Quando scaricate un checksum per una risorsa il cui caricamento del file di checksum non è riuscito, il valore del checksum ricevuto dal client sarà il valore del checksum calcolato in CodeArtifact base ai dati della risorsa caricata.
CodeArtifact i confronti tra checksum fanno distinzione tra maiuscole e minuscole e i checksum calcolati da sono formattati in minuscolo. CodeArtifact Pertanto, se il checksum `909FA780F76DA393E992A3D2D495F468` viene caricato, avrà esito negativo con una mancata corrispondenza del checksum perché non lo considera uguale a. CodeArtifact `909fa780f76da393e992a3d2d495f468`
## Recupero in seguito a mancate corrispondenze nei checksum
Se il caricamento di un checksum non riesce a causa di una mancata corrispondenza del checksum, prova una delle seguenti operazioni per il ripristino:
+ Esegui nuovamente il comando che pubblica l'artefatto Maven. Questo potrebbe funzionare se un problema di rete danneggia il file di checksum. Se questo risolve il problema di rete, il checksum corrisponde e il download ha esito positivo.
+ Eliminare la versione del pacchetto e ripubblicarla. Per ulteriori informazioni, [DeletePackageVersions](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeletePackageVersions.html)consulta *AWS CodeArtifact API Reference*.
# Usa le istantanee di Maven
Un'*istantanea* Maven è una versione speciale di un pacchetto Maven che si riferisce all'ultimo codice filiale di produzione. È una versione di sviluppo che precede la versione di rilascio finale. È possibile identificare una versione istantanea di un pacchetto Maven dal suffisso `SNAPSHOT` aggiunto alla versione del pacchetto. Ad esempio, l'istantanea della versione è. `1.1` `1.1-SNAPSHOT` Per ulteriori informazioni, consulta [Cos'è una versione SNAPSHOT](https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version)? sul sito Web del progetto Apache Maven.
AWS CodeArtifact supporta la pubblicazione e l'utilizzo di istantanee Maven. Le istantanee uniche che utilizzano un numero di versione basato sul tempo sono le uniche istantanee supportate. CodeArtifact non supporta istantanee non univoche generate dai client Maven 2. È possibile pubblicare un'istantanea Maven supportata in qualsiasi repository. CodeArtifact
**Topics**
+ [Pubblicazione di istantanee in CodeArtifact](#maven-snapshot-publishing)
+ [Consumo di versioni istantanee](#maven-consuming-snapshot-versions)
+ [Eliminazione delle versioni istantanee](#maven-deleting-snapshot-versions)
+ [Pubblicazione di istantanee con curl](#maven-snapshot-publishing-curl)
+ [Istantanee e connessioni esterne](#maven-snapshot-external-connections)
+ [Istantanee e repository upstream](#maven-snapshot-upstream-repositories)
## Pubblicazione di istantanee in CodeArtifact
AWS CodeArtifact supporta i modelli di richiesta utilizzati dai client, ad esempio`mvn`, per la pubblicazione di istantanee. Per questo motivo, è possibile seguire la documentazione dello strumento di compilazione o del gestore di pacchetti senza avere una comprensione dettagliata di come vengono pubblicate le istantanee di Maven. Se state facendo qualcosa di più complesso, questa sezione descrive in dettaglio come CodeArtifact gestisce le istantanee.
Quando un'istantanea di Maven viene pubblicata in un CodeArtifact repository, la sua versione precedente viene conservata in una nuova versione chiamata build. Ogni volta che viene pubblicata un'istantanea di Maven, viene creata una nuova versione di build. Tutte le versioni precedenti di un'istantanea vengono mantenute nelle relative versioni di build. Quando viene pubblicata un'istantanea di Maven, lo stato della versione del pacchetto è impostato su `Published` e lo stato della build che contiene la versione precedente è impostato su. `Unlisted` Questo comportamento si applica solo alle versioni del pacchetto Maven in cui la versione del pacchetto ha come suffisso. `-SNAPSHOT`
Ad esempio, le versioni snapshot di un pacchetto Maven chiamato `com.mycompany.myapp:pkg-1` vengono caricate in un repository chiamato. CodeArtifact `my-maven-repo` La versione snapshot è. `1.0-SNAPSHOT` Finora non è stata pubblicata alcuna versione di`com.mycompany.myapp:pkg-1`. Innanzitutto, le risorse della build iniziale vengono pubblicate nei seguenti percorsi:
```
PUT maven/my-maven-repo/com/mycompany/myapp/pkg-1/1.0-SNAPSHOT/pkg-1-1.0-20210728.194552-1.jar
PUT maven/my-maven-repo/com/mycompany/myapp/pkg-1/1.0-SNAPSHOT/pkg-1-1.0-20210728.194552-1.pom
```
Nota che il timestamp `20210728.194552-1` viene generato dal client che pubblica le build di snapshot.
Dopo il caricamento dei file.pom e.jar, l'unica versione esistente nel repository è. `com.mycompany.myapp:pkg-1` `1.0-20210728.194552-1` Ciò accade anche se la versione specificata nel percorso precedente è. `1.0-SNAPSHOT` Lo stato della versione del pacchetto a questo punto è`Unfinished`.
```
aws codeartifact list-package-versions --domain my-domain --repository \
my-maven-repo --package pkg-1 --namespace com.mycompany.myapp --format maven
{
"versions": [
{
"version": "1.0-20210728.194552-1",
"revision": "GipMW+599JmwTcTLaXo9YvDsVQ2bcrrk/02rWJhoKUU=",
"status": "Unfinished"
}
],
"defaultDisplayVersion": null,
"format": "maven",
"package": "pkg-1",
"namespace": "com.mycompany.myapp"
}
```
Successivamente, il client carica il `maven-metadata.xml` file per la versione del pacchetto:
```
PUT my-maven-repo/com/mycompany/myapp/pkg-1/1.0-SNAPSHOT/maven-metadata.xml
```
Quando il file maven-metadata.xml viene caricato correttamente, CodeArtifact crea la versione del `1.0-SNAPSHOT` pacchetto e imposta la `1.0-20210728.194552-1` versione su`Unlisted`.
```
aws codeartifact list-package-versions --domain my-domain --repository \
my-maven-repo --package pkg-1 --namespace com.mycompany.myapp --format maven
{
"versions": [
{
"version": "1.0-20210728.194552-1",
"revision": "GipMW+599JmwTcTLaXo9YvDsVQ2bcrrk/02rWJhoKUU=",
"status": "Unlisted"
},
{
"version": "1.0-SNAPSHOT",
"revision": "tWu8n3IX5HR82vzVZQAxlwcvvA4U/+S80edWNAkil24=",
"status": "Published"
}
],
"defaultDisplayVersion": "1.0-SNAPSHOT",
"format": "maven",
"package": "pkg-1",
"namespace": "com.mycompany.myapp"
}
```
A questo punto, la versione snapshot `1.0-SNAPSHOT` può essere utilizzata in una build. Sebbene `com.mycompany.myapp:pkg-1` nel repository siano presenti due versioni`my-maven-repo`, entrambe contengono le stesse risorse.
```
aws codeartifact list-package-version-assets --domain my-domain --repository \
my-maven-repo --format maven --namespace com.mycompany.myapp \
--package pkg-1 --package-version 1.0-SNAPSHOT--query 'assets[*].name'
[
"pkg-1-1.0-20210728.194552-1.jar",
"pkg-1-1.0-20210728.194552-1.pom"
]
```
L'esecuzione dello stesso `list-package-version-assets` comando mostrato in precedenza con il `--package-version` parametro modificato in `1.0-20210728.194552-1` restituisce un output identico.
Man mano che `1.0-SNAPSHOT` vengono aggiunte altre versioni di al repository, viene creata una nuova versione `Unlisted` del pacchetto per ogni nuova build. Le risorse della versione `1.0-SNAPSHOT` vengono aggiornate ogni volta in modo che la versione faccia sempre riferimento alla build più recente di quella versione. L'aggiornamento `1.0-SNAPSHOT` con le risorse più recenti viene avviato caricando il `maven-metadata.xml` file per la nuova build.
## Consumo di versioni istantanee
Se si richiede un'istantanea, viene restituita la versione con lo stato`Published`. Questa è sempre la versione più recente dell'istantanea di Maven. Puoi anche richiedere una build particolare di un'istantanea utilizzando il numero di versione della build (ad esempio,`1.0-20210728.194552-1`) anziché la versione dell'istantanea (ad esempio,`1.0-SNAPSHOT`) nel percorso URL. Per vedere le versioni di build di un'istantanea Maven, usa l'[ListPackageVersions ](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_ListPackageVersions.html)API nella *Guida CodeArtifact API* e imposta il parametro status su. `Unlisted`
## Eliminazione delle versioni istantanee
Per eliminare tutte le versioni di build di un'istantanea di Maven, usa l'[DeletePackageVersions](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_DeletePackageVersions.html)API, specificando le versioni che desideri eliminare.
## Pubblicazione di istantanee con curl
Se disponi di versioni di snapshot esistenti archiviate in Amazon Simple Storage Service (Amazon S3) o in un altro prodotto di artifact repository, potresti volerle ripubblicare su. AWS CodeArtifact A causa del modo in cui CodeArtifact supporta le istantanee Maven (vedi[Pubblicazione di istantanee in CodeArtifact](#maven-snapshot-publishing)), la pubblicazione di istantanee con un client HTTP generico come ad esempio `curl` è più complessa rispetto alla pubblicazione di versioni di release di Maven, come descritto in. [Pubblicazione con curl](maven-curl.md) Tieni presente che questa sezione non è rilevante se stai creando e distribuendo versioni di snapshot con un client Maven come o. `mvn` `gradle` È necessario seguire la documentazione relativa a quel client.
La pubblicazione di una versione snapshot implica la pubblicazione di una o più build di una versione snapshot. In CodeArtifact, se ci sono *n* build di una versione snapshot, ci saranno *n\$11 CodeArtifact versioni: *n** versioni di build tutte con uno stato di `Unlisted` e una versione snapshot (l'ultima build pubblicata) con uno stato di. `Published` La versione snapshot (ovvero la versione con una stringa di versione che contiene «-SNAPSHOT») contiene un set di risorse identico all'ultima build pubblicata. Il modo più semplice per creare questa struttura utilizzando `curl` è il seguente:
1. Pubblica tutte le risorse di tutte le build utilizzando`curl`.
1. Pubblica il `maven-metadata.xml` file dell'ultima build (ovvero la build con il timbro data-ora più recente) con. `curl` Questo creerà una versione con «`-SNAPSHOT`» nella stringa della versione e con il set di risorse corretto.
1. Utilizza l'[UpdatePackageVersionsStatus](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html)API per impostare lo stato di tutte le versioni di build non più recenti su`Unlisted`.
Utilizzate i seguenti `curl` comandi per pubblicare risorse snapshot (come i file.jar e .pom) per la versione snapshot di un pacchetto: `1.0-SNAPSHOT` `com.mycompany.app:pkg-1`
```
curl --user "aws:$CODEARTIFACT_AUTH_TOKEN" -H "Content-Type: application/octet-stream" \
-X PUT https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_maven_repo/com/mycompany/app/pkg-1/1.0-SNAPSHOT/pkg-1-1.0-20210729.171330-2.jar \
--data-binary @pkg-1-1.0-20210728.194552-1.jar
```
```
curl --user "aws:$CODEARTIFACT_AUTH_TOKEN" -H "Content-Type: application/octet-stream" \
-X PUT https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_maven_repo/com/mycompany/app/pkg-1/1.0-SNAPSHOT/pkg-1-1.0-20210729.171330-2.pom \
--data-binary @pkg-1-1.0-20210728.194552-1.pom
```
Quando si utilizzano questi esempi:
+ *my\$1domain*Sostituiscilo con il tuo nome di CodeArtifact dominio.
+ Sostituiscilo *111122223333* con l' Account AWS ID del proprietario del tuo CodeArtifact dominio.
+ Sostituiscilo *us-west-2* con quello Regione AWS in cui si trova il tuo CodeArtifact dominio.
+ *my\$1maven\$1repo*Sostituiscilo con il nome CodeArtifact del tuo repository.
**Importante**
È necessario anteporre il carattere al valore del `--data-binary` parametro. `@` Quando si inserisce il valore tra virgolette, `@` deve essere incluso tra virgolette.
Potresti avere più di due risorse da caricare per ogni build. Ad esempio, potrebbero esserci Javadoc e file JAR di origine oltre ai file JAR principali e. `pom.xml` Non è necessario pubblicare file di checksum per gli asset della versione del pacchetto perché genera CodeArtifact automaticamente i checksum per ogni risorsa caricata. Per verificare che le risorse siano state caricate correttamente, recuperate i checksum generati utilizzando il `list-package-version-assets` comando e confrontateli con i checksum originali. Per ulteriori informazioni su come CodeArtifact gestisce i checksum di Maven, consulta. [Usa i checksum Maven](maven-checksums.md)
Utilizzate il seguente comando curl per pubblicare il `maven-metadata.xml` file per l'ultima versione di build:
```
curl --user "aws:$CODEARTIFACT_AUTH_TOKEN" -H "Content-Type: application/octet-stream" \
-X PUT https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/maven/my_maven_repo/com/mycompany/app/pkg-1/1.0-SNAPSHOT/maven-metadata.xml \
--data-binary @maven-metadata.xml
```
Il `maven-metadata.xml` file deve fare riferimento ad almeno una delle risorse nell'ultima versione di build dell'``elemento. Inoltre, il `` valore deve essere presente e deve corrispondere al timestamp riportato nei nomi dei file delle risorse. Ad esempio, per la `20210729.171330-2` build pubblicata in precedenza, il contenuto di `maven-metadata.xml` sarebbe:
```
com.mycompany.app
pkg-1
1.0-SNAPSHOT
20210729.171330
2
20210729171330
jar
1.0-20210729.171330-2
20210729171330
pom
1.0-20210729.171330-2
20210729171330
```
Dopo `maven-metadata.xml` la pubblicazione, l'ultimo passaggio consiste nell'impostare tutte le altre versioni di build (ovvero tutte le versioni di build tranne la build più recente) per avere lo stato della versione del pacchetto di`Unlisted`. Ad esempio, se la `1.0-SNAPSHOT` versione ha due build, di cui la prima build è`20210728.194552-1`, il comando su cui impostare quella build `Unlisted` è:
```
aws codeartifact update-package-versions-status --domain my-domain --domain-owner 111122223333 \
--repository my-maven-repo --format maven --namespace com.mycompany.app --package pkg-1 \
--versions 1.0-20210728.194552-1 --target-status Unlisted
```
## Istantanee e connessioni esterne
Le istantanee di Maven non possono essere recuperate da un archivio pubblico Maven tramite una connessione esterna. AWS CodeArtifact supporta solo l'importazione di versioni di release di Maven.
## Istantanee e repository upstream
In generale, le istantanee di Maven funzionano allo stesso modo delle versioni di release di Maven se utilizzate con repository upstream, ma esiste una limitazione se si prevede di pubblicare istantanee della stessa versione del pacchetto su due repository che hanno una relazione a monte. Ad esempio, supponiamo che ci siano due repository in un dominio e che dove sia un upstream di. AWS CodeArtifact `R` `U` `U` `R` Se pubblichi una nuova build in`R`, quando un client Maven richiede l'ultima build di quella versione snapshot, CodeArtifact restituisce la versione più recente da. `U` Questo può essere inaspettato poiché l'ultima versione è ora disponibile, no. `R` `U` Esistono due modi per evitarlo:
1. Non pubblicate build di una versione istantanea come `1.0-SNAPSHOT` in`R`, se `1.0-SNAPSHOT` esiste in. `U`
1. Usa i controlli di origine CodeArtifact del pacchetto per disabilitare gli upstream su quel pacchetto in. `R` Quest'ultimo ti permetterà di pubblicare versioni di `1.0-SNAPSHOT` in`R`, ma `R` impedirà anche di recuperare altre versioni di quel pacchetto `U` che non siano già state conservate.
# Richiesta di pacchetti Maven da upstream e connessioni esterne
## Importazione di nomi di risorse standard
Quando importa una versione di pacchetto Maven da un repository pubblico, come Maven Central, CodeArtifact AWS tenta di importare tutte le risorse in quella versione del pacchetto. Come descritto in, l'importazione avviene quando: [Richiesta di una versione del pacchetto con repository upstream](repo-upstream-behavior.md)
+ Un client richiede una risorsa Maven da un repository. CodeArtifact
+ La versione del pacchetto non è già presente nel repository o nei suoi upstream.
+ Esiste una connessione esterna raggiungibile a un repository Maven pubblico.
Anche se il client potrebbe aver richiesto solo una risorsa, CodeArtifact tenta di importare tutte le risorse che riesce a trovare per quella versione del pacchetto. Il modo in cui CodeArtifact scopre quali risorse sono disponibili per una versione del pacchetto Maven dipende dal particolare archivio pubblico. Alcuni repository Maven pubblici supportano la richiesta di un elenco di risorse, ma altri no. Per i repository che non forniscono un modo per elencare le risorse, CodeArtifact genera una serie di nomi di risorse che è probabile che esistano. Ad esempio, quando viene richiesta una risorsa della versione `junit 4.13.2` del pacchetto Maven, CodeArtifact tenterà di importare le seguenti risorse:
+ `junit-4.13.2.pom`
+ `junit-4.13.2.jar`
+ `junit-4.13.2-javadoc.jar`
+ `junit-4.13.2-sources.jar`
## Importazione di nomi di asset non standard
Quando un client Maven richiede una risorsa che non corrisponde a uno dei modelli sopra descritti, CodeArtifact verifica se quella risorsa è presente nell'archivio pubblico. Se la risorsa è presente, verrà importata e aggiunta al record della versione del pacchetto esistente, se esistente. Ad esempio, la versione del pacchetto Maven `com.android.tools.build:aapt2 7.3.1-8691043` contiene le seguenti risorse:
+ `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`
Quando un client richiede il file POM, se non CodeArtifact è in grado di elencare gli asset della versione del pacchetto, il POM sarà l'unica risorsa importata. Questo perché nessuna delle altre risorse corrisponde ai modelli di denominazione degli asset standard. Tuttavia, quando il client richiede una delle risorse JAR, tale risorsa verrà importata e aggiunta alla versione del pacchetto esistente archiviata in CodeArtifact. Le versioni del pacchetto presenti sia nel repository più a valle (l'archivio verso cui il client ha effettuato la richiesta) che nel repository con la connessione esterna collegata verranno aggiornate per contenere la nuova risorsa, come descritto in. [Package retention dai repository upstream](repo-upstream-behavior.md#package-retention-upstream-repos)
Normalmente, una volta che una versione del pacchetto viene conservata in un CodeArtifact repository, non è influenzata dalle modifiche apportate ai repository upstream. Per ulteriori informazioni, consulta [Package retention dai repository upstream](repo-upstream-behavior.md#package-retention-upstream-repos). Tuttavia, il comportamento degli asset Maven con nomi non standard descritto in precedenza è un'eccezione a questa regola. Sebbene la versione downstream del pacchetto non cambierà senza che un client richieda una risorsa aggiuntiva, in questa situazione, la versione del pacchetto conservata viene modificata dopo essere stata inizialmente mantenuta e quindi non è immutabile. Questo comportamento è necessario perché altrimenti le risorse Maven con nomi non standard non sarebbero accessibili tramite. CodeArtifact Il comportamento si attiva anche se vengono aggiunti a una versione del pacchetto Maven su un repository pubblico dopo che la versione del pacchetto è stata conservata in un repository. CodeArtifact
## Verifica delle origini delle risorse
Quando si aggiunge una nuova risorsa a una versione del pacchetto Maven precedentemente conservata, CodeArtifact conferma che l'origine della versione del pacchetto conservata è la stessa dell'origine della nuova risorsa. Ciò impedisce la creazione di una versione del pacchetto «mista» in cui risorse diverse provengono da diversi archivi pubblici. Senza questo controllo, potrebbe verificarsi una combinazione di risorse se una versione del pacchetto Maven viene pubblicata su più di un repository pubblico e tali repository fanno parte del grafico upstream di un CodeArtifact repository.
## Importazione di nuove risorse e dello stato delle versioni dei pacchetti nei repository upstream
[Lo stato della versione del pacchetto](packages-overview.md#package-version-status) delle versioni dei pacchetti negli archivi upstream può CodeArtifact impedire il mantenimento di tali versioni nei repository downstream.
Ad esempio, supponiamo che un dominio abbia tre repository:`repo-A`,, e `repo-B``repo-C`, dove si trova un upstream di e `repo-B` sta a monte di. `repo-A` `repo-C` `repo-B`
![\[Un diagramma del funzionamento dei nuovi asset e delle nuove versioni dei pacchetti nei repository upstream.\]](http://docs.aws.amazon.com/it_it/codeartifact/latest/ug/images/Maven-new-asset-pv-upstream.png)
La versione `7.3.1` del pacchetto Maven `com.android.tools.build:aapt2` è presente in `repo-B` e ha uno stato di. `Published` Non è presente in. `repo-A` Se un client richiede una risorsa di questa versione del pacchetto da`repo-A`, la risposta sarà 200 (OK) e la versione del pacchetto Maven `7.3.1` verrà mantenuta. `repo-A` Tuttavia, se lo stato della versione del pacchetto `7.3.1` in `repo-B` è `Archived` o`Disposed`, la risposta sarà 404 (Not Found) perché le risorse delle versioni del pacchetto in questi due stati non sono scaricabili.
Nota che l'impostazione del [controllo di origine del pacchetto su](package-origin-controls.md) `upstream=BLOCK` for `com.android.tools.build:aapt2` in `repo-A``repo-B`, `repo-C` impedirà il recupero di nuove risorse per tutte le versioni di quel pacchetto`repo-A`, indipendentemente dallo stato della versione del pacchetto.
# Risoluzione dei problemi con Maven
Le seguenti informazioni potrebbero aiutarti a risolvere i problemi più comuni con Maven e. CodeArtifact
## Disabilita i put paralleli per correggere l'errore 429: Troppe richieste
A partire dalla versione 3.9.0, Maven carica gli artefatti del pacchetto in parallelo (fino a 5 file alla volta). Ciò può causare la risposta occasionale con CodeArtifact un codice di risposta all'errore 429 (Too Many Requests). Se si verifica questo errore, è possibile disabilitare le uscite parallele per risolverlo.
Per disabilitare le uscite parallele, impostate la `aether.connector.basic.parallelPut` proprietà su `false` nel vostro profilo nel `settings.xml` file, come mostrato nell'esempio seguente:
```
default
false
```
Per ulteriori informazioni, consulta le opzioni di [configurazione di Artifact Resolver](https://maven.apache.org/resolver/configuration.html) nella documentazione di Maven.