2012-06-24 11 views
10

Sto costruendo un progetto, costituito da diversi moduli (a volte non correlati) e altri moduli java non standard (creati con ANT).Distribuire Maven: forzare la distribuzione anche se esiste già un artefatto

Ogni modulo Maven viene distribuito al repository delle versioni al completamento.

Se la compilazione fallisce nel mezzo, potrei avere già alcuni moduli già distribuiti, quindi se provo a ricostruire, il nuovo tentativo di distribuzione fallirà poiché le risorse sono già state distribuite.

È possibile forzare una distribuzione o, invece, rimuovere la risorsa distribuita prima di distribuirla di nuovo?

+0

try mvn release: rollback – om39a

+0

Perché la distribuzione fallire? Se distribuisci artefatto con la stessa versione, sovrascriverà solo quello esistente. –

+3

Andrew - AFAIK, se provi a ridistribuire un artefatto esistente, fallirai. –

risposta

8

Sembra che gli amministratori del middleware abbiano configurato l'istanza di repository remoto (Nexus o Artifactory o qualsiasi altra cosa) per non consentire la ridistribuzione degli artefatti, e come @khmarbaise dice che ci sono buone ragioni per farlo. Nexus può essere configurato per consentire la cancellazione degli artefatti dagli utenti in un particolare ruolo o con privilegi di eliminazione degli artefatti. Se i tuoi amministratori lo hanno impostato in questo modo, forse puoi richiedere il privilegio di eliminazione e rimuovere gli artefatti da offendere. O forse l'amministratore Nexus accetterà di farlo per te.

Se nessuna di queste è possibile, qui ci sono alcune cose da provare che potrebbero evitare che ciò accada in futuro:

  1. Se si utilizza il plugin release, fare una prova generale (-DdryRun=true sul rilascio : prepara la riga di comando) prima. Maven dovrebbe segnalare eventuali errori senza impegnarsi in SCM.
  2. Provare a eseguire mvn install sul gruppo di progetti. Questo installerà le risorse sul tuo repository locale, non sul telecomando. Se c'è un problema, puoi eliminare gli artefatti dal tuo repository locale e ricominciare da zero, ripetendo finché non ottieni una compilazione completa.
  3. Se si sta eseguendo una build multi-modulo, ci sono command line options che consentono di riprendere una build Maven da un particolare project forward.
  4. Definire -Dmaven.deploy.skip=true sulla riga di comando Maven. Questo è simile al suggerimento n. 2, ad eccezione del fatto che Maven carica effettivamente & configura lo deploy plugin, ma non eseguirà l'effettiva distribuzione sul repository remoto. Una volta che tutto funziona, rimuovere la proprietà di salto.
+0

Tutti i buoni suggerimenti. Penso che andrò per l'opzione 4 o simili ... Thx! –

+0

Ho un problema simile, tutto è andato bene fino a quando ho ottenuto un 502 (Errore Proxy) presumo che il mio server di uni pensato che la mia connessione sia una minaccia. Ora ottengo 400 (Bad Request) perché gli artefatti sono già sul server nexus. C'è un modo per riprendere un rilascio: eseguire? Posso cancellare gli artefatti ma questo è molto lavoro nel pannello di controllo di nexus. Sembra che debba cancellare a mano ogni sottocartella di versione del progetto multi-modulo. Proverò a caricare da dentro la rete uni la prossima volta, però! – DarthB

2

Le opzioni possibili sono state aumentate;)

utilizzare il parametro deployAtEnd (Maggiori informazioni: here). Con questo parametro, le risorse utente vengono distribuite solo se tutti gli artefatti sono stati creati correttamente.

4

So che potrebbe essere tardi, ma in Nexus è disponibile un'opzione che consente la ridistribuzione degli artefatti.

enter image description here

Basta selezionare i repository nella sinistra, scegliere il repository che si desidera modificare il criterio e quindi impostare per permettere Ridistribuisci.

+0

Questa è una buona opzione, ma sono interessato a tale capacità solo dalla mia build e non consentire a nessuno di ri-distribuire un artefatto rilasciato. Posso abilitarlo al momento della compilazione e disabilitare quando la compilazione è terminata? –

+0

non penso sia possibile perché chi decide se il manufatto può essere ridistribuito è il server, non il client – leozin

Problemi correlati