Chi siamo
In 1C, non solo sviluppiamo la piattaforma in e , ma anche applicazioni in Java, in particolare un nuovo ambiente di sviluppo basato su Eclipse e un server profondamente integrato con la piattaforma del messenger - .
Introduzione
Come sistema di build per le applicazioni Java, utilizziamo più frequentemente Maven e in questo breve articolo vorremmo parlare di uno dei problemi con cui ci siamo trovati a confrontarci durante l'organizzazione dello sviluppo e di un approccio che ha permesso di superare questo problema.
Presupposti e flusso di lavoro
A causa della specificità dello sviluppo nei nostri progetti Maven, utilizziamo un numero considerevole di moduli, dipendenze e progetti secondari. Il numero di file pom in un singolo albero può raggiungere decine o addirittura centinaia.
Sembrerebbe: non c'è nulla di grave, una volta creati li dimentichiamo. Se è necessario apportare modifiche o aggiungere elementi a tutti i file contemporaneamente, ci sono molti strumenti utili negli editor e IDE. E qual è la modifica più comune nel pom.xml? Riteniamo che sia la modifica delle versioni del progetto e delle dipendenze. È possibile che qualcuno voglia contestare questo, ma per noi è così. La ragione risiede nel fatto che, insieme al core, sviluppiamo parallelamente molte librerie proprie e per una costante riproducibilità dei risultati di build e test, l'uso dei snapshot non ci sembra un approccio comodo. Per questo motivo, dobbiamo innalzare il numero di versione nei progetti ad ogni build.
Inoltre, a volte lo sviluppatore ha bisogno di costruire la propria branch di una libreria e verificare il suo funzionamento con tutte le dipendenze, per cui è necessario cambiare manualmente la versione in tutte.
Soluzione iniziale
Con così tanti cambiamenti frequenti e molteplici versioni, desideriamo semplificare e automatizzare il processo all'interno del CI. Qui viene in aiuto un plugin noto e conveniente versions-maven-plugin — lo colleghiamo e lo eseguiamo
mvn -N versions:set -DnewVersion=2.0.1
e Maven farà tutto come deve: passerà attraverso l'gerarchia dall'alto verso il basso, sostituirà tutte le versioni - bellissimo! Ora rimane solo alzare una pull-request, i colleghi esamineranno le modifiche e possiamo rapidamente integrarsi nel trunk. Velocemente? Macché. Un paio di centinaia pom.xml in revisione, e questo senza contare il codice. Inoltre, nessuno è al sicuro dai conflitti di merge con così tanti file modificati. Vale la pena notare che nel processo CI le versioni vengono aggiornate automaticamente insieme ai cambiamenti di funzionalità, non separatamente.
Nuove funzionalità
Ci siamo calmati per un po’ e, rassegnati, abbiamo continuato a vivere così, fino a quando i ragazzi di non hanno incluso in maven, a partire dalla versione 3.5.0-beta-1, il supporto per i cosiddetti "sostituti" delle versioni (placeholders). L’idea di questi sostituti è che pom.xml anziché indicare un numero di versione specifico del progetto, si usano delle variabili ${revision}, ${sha1} e ${changelist}. I valori di queste proprietà possono essere definiti o all'interno dell'elemento <properties>, oppure possono essere definiti tramite la proprietà di sistema
mvn -Drevision=2.0.0 clean package
I valori delle proprietà di sistema hanno la precedenza rispetto ai valori definiti in <properties>.
Padre
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>18<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<name>First CI Friendly<\/name>
<version>${revision}${sha1}${changelist}<\/version>
…
<properties>
<revision>1.3.1<\/revision>
<changelist>-SNAPSHOT<\/changelist>
<sha1\/>
<\/properties>
<\/project>
Discendente
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<version>${revision}${sha1}${changelist}<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-child<\/artifactId>
…
<\/project>
Se si desidera raccogliere la versione 2.0.0-SNAPSHOT, basta utilizzare
mvn -Drevision=2.0.0 clean package
Se si desidera effettuare un rilascio, basta azzerare SNAPSHOT
mvn -Dchangelist= clean package
*Gli esempi sopra sono tratti da sito del Maven Apache Project
La dura realtà
Tutto bene e bello, è ora di provare un senso di soddisfazione, ma no. Si scopre che per install e deploy questo metodo non va bene, poiché nelle descrizioni degli artefatti pubblicati nel repository non verrà sostituito ${revision} con il suo valore e maven non capirà più di cosa si stia parlando.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Luce in fondo al tunnel
Dobbiamo cercare una soluzione al problema. La situazione potrebbe essere salvata da . Questo plugin consente tutte le variabili nel pom, ma rimuove anche una quantità considerevole di altre informazioni necessarie solo durante la compilazione e non richieste per l'importazione di artefatti pubblicati in altri progetti. Inoltre, il plugin «appiattisce» tutte le dipendenze parent-child, producendo pom piatti che includono tutto il necessario. Il problema era che tagliava via «troppe cose superflue», il che non ci soddisfaceva affatto. Dopo aver esaminato le informazioni sullo sviluppo di questo plugin, abbiamo scoperto di non essere gli unici nell'universo e, già nell'agosto 2018, è stata creata su GitHub una pull-request nel repository del plugin con la richiesta di poter definire autonomamente come «manipolare» il pom.xml. Gli sviluppatori hanno ascoltato le richieste e già a dicembre, con l'uscita della nuova versione 1.1.0, nel flatten-maven-plugin è stata introdotta una nuova modalità resolveCiFriendliesOnly, che è arrivata al momento giusto: mantiene il pom.xml così com'è, tranne per l'elemento <version> e consente ${revision}, ${sha1} e ${changelist}.
Aggiungiamo il plugin al progetto
<plugins>
<plugin>
org.codehaus.mojo
flatten-maven-plugin
1.1.0
<configuration>
true
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
flatten
process-resources
<goals>
flatten
</goals>
</execution>
<execution>
flatten.clean
clean
<goals>
clean
</goals>
</execution>
</executions>
</plugin>
</plugins>
Fatto!
Happy end
Da ora in poi, per cambiare la versione dell'intero progetto e informare tutte le dipendenze, è sufficiente modificare l'elemento <revision> in un solo pom di root. pom.xmlUna sola revisione riceve in feedback, invece di una cento o due di questi file con modifiche identiche. Inoltre, non c'è più bisogno di utilizzare versions-maven-plugin.
Fonte: habr.com
