Chi siamo
In 1C sviluppiamo non solo una piattaforma su и , ma anche applicazioni Java, in particolare il nuovo ambiente di sviluppo basato su Eclipse e un server di messaggistica profondamente integrato con la piattaforma - .
Iscrizione
Utilizziamo molto spesso Maven come sistema di compilazione per applicazioni Java e in questo breve articolo vorremmo parlare di uno dei problemi che abbiamo dovuto affrontare nel processo di organizzazione dello sviluppo e dell'approccio che ci ha permesso di superare questo problema.
Prerequisiti e flusso di lavoro
A causa delle specificità dello sviluppo nei nostri progetti Maven, utilizziamo molti moduli, dipendenze e progetti figli. Il numero di file pom in un albero può essere dell'ordine delle decine o addirittura delle centinaia.
Sembrerebbe: niente di grave, l'hanno creato una volta e se ne sono dimenticati. Se hai bisogno di modificare o aggiungere qualcosa in tutti i file contemporaneamente, ci sono molti strumenti utili negli editor e negli IDE. Qual è la modifica regolare più comune a pom.xml? Riteniamo che i cambiamenti nelle versioni e nelle dipendenze del progetto. Forse qualcuno vorrà discuterne, ma questa è esattamente la nostra situazione. Il motivo sta nel fatto che, insieme al kernel, stiamo sviluppando contemporaneamente molte delle nostre librerie e, data la costante riproducibilità dei risultati di compilazione e test, l'uso di snapshot non ci sembra un approccio conveniente. Per questo motivo è necessario aumentare il numero di versione nei progetti ad ogni build.
Inoltre, di tanto in tanto, uno sviluppatore deve creare il proprio ramo di una libreria e verificarne la funzionalità rispetto a tutte le dipendenze, per cui deve modificare manualmente la versione di tutte.
Soluzione iniziale
Con modifiche di versione così frequenti e multiple, voglio semplificare e automatizzare il processo all'interno di CI. È qui che viene in soccorso un plugin comodo e noto. plugin-versioni-maven - collegalo e avvialo
mvn -N versioni:set -DnewVersion=2.0.1
e Maven farà tutto come dovrebbe: percorrerà la gerarchia dall'alto verso il basso, sostituendo tutte le versioni: bellezza! Ora non resta che sollevare una richiesta pull, i colleghi esamineranno le modifiche e potrai unirti rapidamente al trunk. Velocemente? Non importa come sia. Un paio di centinaia pom.xml per la revisione, e questo non conta il codice. Inoltre, nessuno è al sicuro dai conflitti di unione con un numero così elevato di file modificati. Va notato qui che nel processo CI, le modifiche alla versione avvengono automaticamente insieme alle modifiche alla funzionalità e non in qualche modo separatamente.
Nuove funzionalità
Per un po 'ci siamo calmati e, rassegnati, abbiamo vissuto così fino all'uscita dei ragazzi A partire dalla versione 3.5.0-beta-1, Maven non includeva il supporto per i cosiddetti “placeholder”. L'essenza di questi sostituti è questa pom.xml al posto dell'indicazione specifica della versione del progetto vengono utilizzate delle variabili ${revisione}, ${sha1} и ${lista modifiche}. I valori di queste proprietà stesse sono impostati nell'elementoproprietà>, oppure possono essere definiti tramite una proprietà di sistema
mvn -Drevision=2.0.0 pacchetto pulito
I valori delle proprietà di sistema hanno la precedenza sui valori definiti inproprietà>.
Il genitore
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-genitore
Primo CI amichevole
${revisione}${sha1}${lista modifiche}
...
1.3.1
-ISTANTANEA
Discendente
4.0.0
org.apache.maven.ci
ci-genitore
${revisione}${sha1}${lista modifiche}
org.apache.maven.ci
ci-bambino
...
Se vuoi creare la versione 2.0.0-SNAPSHOT, usa semplicemente
mvn -Drevision=2.0.0 pacchetto pulito
Se vuoi fare un rilascio, resetta semplicemente SNAPSHOT
mvn -Dchangelist= pacchetto pulito
*Gli esempi sopra riportati sono tratti da sul sito web del progetto Maven Apache
Realtà dura
Tutto è buono e sano, è il momento di provare un senso di soddisfazione, ma no. Risulta che questo metodo non funzionerà per l'installazione e la distribuzione, poiché non verrà sostituito nelle descrizioni degli artefatti pubblicati nel repository ${revisione} sul suo significato e gli esperti non capiranno più di cosa si tratta.
org.apache
apache
${revisione}
Una luce in fondo a un tunnel
Dobbiamo cercare una soluzione al problema. Avrei potuto salvare la situazione . Questo plugin risolve tutte le variabili nel pom, ma allo stesso tempo elimina molte altre informazioni che sono necessarie solo durante l'assemblaggio e non sono necessarie quando si importano artefatti pubblicati in altri progetti. Il plugin inoltre “sistema” tutte le dipendenze genitore-figlio e, di conseguenza, ottieni un pom piatto che include tutto ciò di cui hai bisogno. L'inconveniente è che elimina troppo "extra", il che non ci andava affatto bene. Dopo aver studiato le informazioni sullo sviluppo di questo plugin, si è scoperto che non siamo gli unici nell'universo e nell'agosto 2018 è stata creata una pull-request su Github nel repository dei plugin con il desiderio di renderlo possibile per determinare da soli come "rovinare" pom.xml. Gli sviluppatori hanno ascoltato le voci di coloro che soffrivano e già a dicembre, con il rilascio della nuova versione 1.1.0, nel plugin flatten-maven è apparsa una nuova modalità, "resolveCiFriendliesOnly", più adatta che mai - lascia pom.xml così com'è, ad eccezione dell'elemento e permette ${revisione}, ${sha1} и ${lista modifiche}.
Aggiunta di un plugin al progetto
org.codehaus.mojo
flatten-maven-plugin
1.1.0
VERO
risolvereCiFriendliesOnly
appiattire
risorse-processo
appiattire
appiattire.pulire
pulito
pulito
Fatto!
Lieto fine
D'ora in poi, per cambiare la versione dell'intero progetto e farlo sapere a tutte le dipendenze, basterà modificare l'elementorevisione> solo nella radice pom.xml. Alla revisione non arrivano cento o due di questi file con la stessa modifica, ma uno. Bene, non è necessario utilizzarlo plugin-versioni-maven.
Fonte: habr.com