Sto tentando di creare un modo in cui è possibile ottenere build ermetici pur facendo affidamento su dipendenze SNAPSHOT nel progetto.Creazione di build meccaniche ermetiche
Ai fini della esempio, dire che ho un progetto che ha una struttura di dipendenze come questa:
┌ other-1.2-SNAPSHOT
mine-1.2.3 ──┤
└ thing-3.1-SNAPSHOT ── gizmo-6.1.3-SNAPSHOT
Quello che vorrei fare è risolvere tutte le dipendenze SNAPSHOT a livello locale per qualcosa che è legato alla mia versione corrente e quindi distribuirli come release al repository di release del mio Nexus. Non tutte queste dipendenze sono interne, quindi non posso semplicemente rilasciarle su ciascuna.
Quindi, in questo esempio, other-1.2-SNAPSHOT sarebbe diventato qualcosa di simile other-1.2-mine-1.2.3 e thing-3.1-SNAPSHOT sarebbe diventato thing-3.1-mine-1.2.3. Questo è relativamente banale in circa 60 linee di python.
Il problema, tuttavia, consiste nel risolvere gli SNAPSHOT transitivi nelle versioni concrete. Quindi ho anche bisogno di convertire gizmo-6.1.3-SNAPSHOT in gizmo-6.1.3-mine.1.2.3 e avere thing-3.1-mine-1.2.3 dipende da questo.
Questo è solo un esempio di un modo in cui ottenere ciò che voglio. L'obiettivo è che in un anno o due lungo la strada posso controllare il mio ramo di rilascio per la versione 1.2.3 ed essere in grado di eseguire mvn clean package o simili senza doversi preoccupare di risolvere dipendenze SNAPSHOT scadute da tempo.
E 'importante che questo ramo sia compilabile e non solo mantiene tutte le dipendenze che utilizzano qualcosa come il jar-and-dependencies funzionalità del plugin di montaggio. Mi piacerebbe potenzialmente poter modificare i file di origine e creare un altro build di rilascio (ad esempio applicando un hotfix).
Quindi,
- C'è qualcosa di simile a disposizione che sarà in grado di convertire le dipendenze SNAPSHOT in modo ricorsivo per essere concreti?
- Ci sono dei plugin che gestiscono questo tipo di cose per te? Il plug-in di rilascio era promettente con alcune opzioni di configurazione sul suo obiettivo
branchma non risolve i deps esterni nella misura desiderata. - Sono disponibili altre tecniche per creare build ermetici di Maven?
Suona come un anti maven hack per me. In Maven, una delle regole fondamentali di base è ** Convenzione sulla configurazione **. Se le dipendenze vengono create da soli, è necessario gestire/utilizzare correttamente la versione SNAPSHOT/RELEASE. Se provengono da qualche altra parte, dovresti sempre usare la versione più recente (non la versione SNAPSHOT). Dai una seconda occhiata a [Maven The Complete Reference - sezione 3.3.1] (http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html#pom-reationships -seleziona-versioni) e vedere perché SNAPSHOT è utilizzato in Maven. – yorkw
Comprendo molto bene i fondamenti di Maven. Tuttavia, vivo nel mondo reale con scadenze e librerie di terze parti che sono incredibilmente utili e tuttavia siedono su versioni SNAPSHOT per lunghi periodi di tempo. Jason Van Zyl, qualcuno che potresti conoscere, ammette perfino che l'idea di avere un sistema pesante per processi attorno alle uscite è stato un grosso errore (e sta cambiando con Tesla). A meno di mantenere le forcelle interne di tutto il progetto che consumiamo, quello che sto facendo è in realtà un salto da gigante meglio di quanto farebbero molti altri. –
bene anche nel mondo reale dovrebbe essere preso in considerazione qualche motivo. Stai combattendo il sistema qui. Come hai detto, le istantanee non vivono abbastanza a lungo, anche se si utilizzano istantanee con timestamp per fare affidamento sulla risoluzione degli artefatti. Il mio approccio sarebbe quello di utilizzare la dipendenza e distribuire plugin per recuperare tutte le risorse e distribuire le dipendenze dello snapshot conosciute nel proprio repository Maven utilizzando uno script o un plug-in self-made-maven. Forse anche parlare con gli altri aggeggi aiuta: se riescono a rilasciare versioni beta dei loro artefatti, ci si può fidare di quelli senza troppi problemi. – wemu