Alconost s'occupe professionnellement de
Dans 1C, nous développons non seulement la plateforme. sur et , mais aussi des applications en Java – en particulier un nouvel environnement de développement. basés sur Eclipse et un serveur profondément intégré à la plateforme de messagerie – .
Introduction
En tant que système de construction pour les applications Java, nous utilisons le plus souvent Maven, et dans cet article, nous aimerions parler d'un des problèmes rencontrés lors de l'organisation du développement, ainsi que d'une approche qui a permis de surmonter ce problème.
Préalables et processus de travail
En raison de la spécificité de développement dans nos projets Maven, nous utilisons assez de modules, de dépendances et de sous-projets. Le nombre de fichiers POM dans un arbre peut se compter par dizaines, voire centaines.
Cela semble inoffensif : une fois créé, on l'oublie. S'il faut changer ou ajouter quelque chose dans tous les fichiers en même temps, il existe de nombreux outils pratiques dans les éditeurs et les IDE. Quelle est la modification régulière la plus courante du pom.xml ? Nous pensons qu'il s'agit du changement de versions des projets et des dépendances. Peut-être que quelqu'un voudra contester cela, mais c'est ainsi que ça se passe chez nous. La raison en est que, parallèlement au cœur, nous développons de nombreuses bibliothèques internes, et pour une reproductibilité constante des résultats de construction et de test, l'utilisation de snapshots ne nous semble pas pratique. C'est pourquoi nous devons augmenter le numéro de version dans les projets à chaque construction.
Le développeur a également parfois besoin de construire sa propre branche de n'importe quelle bibliothèque et de vérifier son bon fonctionnement avec toutes les dépendances, pour cela il faut manuellement changer la version dans chacune d'elles.
Solution initiale
Avec ces changements fréquents et multiples de versions, le processus dans le cadre du CI souhaite être simplifié et automatisé. C'est là qu'un plugin public connu se présente comme une aide. versions-maven-plugin – nous l'ajoutons et le lançons
mvn -N versions:set -DnewVersion=2.0.1
et Maven fera tout comme il se doit : il parcourra la hiérarchie de haut en bas, remplacera toutes les versions – superbe ! Maintenant, il ne reste plus qu'à soumettre la pull request, les collègues examineront les modifications, et nous pourrons rapidement nous intégrer dans le trunk. Rapidement ? Pas si sûr. Quelques centaines. pom.xml Lors de la révision, sans compter le code. De plus, personne n'est à l'abri des conflits de fusion avec un si grand nombre de fichiers modifiés. Il convient de noter qu'au cours du processus d'intégration continue, les changements de version se produisent automatiquement en même temps que les modifications de fonctionnalité, et non séparément.
Nouvelles fonctionnalités
Nous avons été tranquilles un certain temps et, résignés, avons continué à vivre ainsi, jusqu'à ce que les gars de n'intègrent dans Maven, à partir de la version 3.5.0-beta-1, le support des 'remplaçants' de version (placeholders). Le principe de ces remplaçants est que pom.xml au lieu d'indiquer une version spécifique du projet, des variables sont utilisées, ${revision}, ${sha1} et ${changelist}. Les valeurs de ces propriétés sont définies soit dans l'élément <properties>, soit elles peuvent être définies via une propriété système.
mvn -Drevision=2.0.0 clean package
Les valeurs des propriétés système ont la priorité sur les valeurs définies dans <properties>.
Parent
<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>
Enfant
<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>
Si vous souhaitez construire la version 2.0.0-SNAPSHOT, vous utilisez simplement
mvn -Drevision=2.0.0 clean package
Si vous souhaitez faire un release, il suffit de réinitialiser le SNAPSHOT.
mvn -Dchangelist= clean package
*Les exemples ci-dessus sont tirés de sur le site Maven Apache Project.
La dure réalité
Tout est bien et bon, il est temps de ressentir un sentiment de satisfaction, mais non. Il s'avère que cette méthode ne convient pas pour install et deploy, car les descriptions des artefacts publiés dans le dépôt ne remplaceront pas ${revision} par sa valeur et Maven ne comprendra plus de quoi il s'agit.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
La lumière au bout du tunnel
Il faut chercher une solution. La situation pourrait être sauvée par . Ce plugin permet de résoudre toutes les variables dans le pom, mais il coupe également beaucoup d'autres informations qui ne sont nécessaires que lors de la construction et qui ne sont pas nécessaires lors de l'importation des artefacts publiés dans d'autres projets. De plus, le plugin « aplanit » toutes les dépendances parent-enfant, et au final, on obtient des pom plats qui incluent tout ce qui est nécessaire. Le problème était qu'il était trop destructeur en supprimant trop d'éléments non souhaités, ce qui ne nous convenait pas du tout. Après avoir étudié les informations sur le développement de ce plugin, il s'est avéré que nous n'étions pas seuls dans l'univers, et déjà en août 2018, un pull-request avait été créé sur GitHub dans le dépôt du plugin, demandant la possibilité de définir soi-même comment « déformer » le pom.xml. Les développeurs ont écouté les voix des nécessiteux, et déjà en décembre, avec la sortie de la nouvelle version 1.1.0 du flatten-maven-plugin, un nouveau mode resolveCiFriendliesOnly a été introduit, qui convient comme jamais – il laisse le pom.xml tel quel, à l'exception de l'élément <version> et permet ${revision}, ${sha1} et ${changelist}.
Ajoutons le plugin au projet
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.1.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
C'est fait !
Happy end
Désormais, pour changer la version de l'ensemble du projet et en informer toutes les dépendances, il suffit de modifier l'élément <revision> dans un seul pom racine pom.xml. Ainsi, un seul fichier arrive pour révision plutôt qu'une centaine de fichiers avec des modifications identiques. De plus, la nécessité d'utiliser versions-maven-plugin.
Source : habr.com
