Expérience de l'utilisation du plugin flatten-maven pour simplifier la gestion des versions dans les projets maven

À propos de nous

Dans 1C, nous développons non seulement la plate-forme 1C: Enterprise en C ++ et JavaScript , mais également des applications Java - en particulier, le nouvel environnement de développement Enterprise Development Tools basé sur Eclipse et un serveur profondément intégré à la plate-forme de messagerie - Interaction Systems .

Entrée

Le plus souvent, nous utilisons maven comme système pour assembler des applications Java, et dans ce court article, nous aimerions parler de l'un des problèmes que nous avons dû traiter pendant le processus de développement et de l'approche qui nous a permis de surmonter ce problème.

Contexte et workflow

En raison des spécificités de développement de nos projets maven, nous utilisons beaucoup de modules, de dépendances et de projets enfants. Le nombre de fichiers pom dans une arborescence peut être des dizaines voire des centaines.



Il semblerait: ça va, une fois créé et oublié. Si vous devez modifier ou ajouter quelque chose dans tous les fichiers à la fois, il existe de nombreux outils pratiques dans les éditeurs et les IDE. Et quel est le changement régulier le plus courant vers pom.xml? Nous pensons que la modification des versions et des dépendances du projet. Peut-être que quelqu'un veut discuter de cela, mais c'est le cas avec nous. La raison en est que, avec le noyau, nous développons simultanément plusieurs de nos propres bibliothèques, et pour la reproductibilité constante de l'assemblage et des résultats des tests, l'utilisation d'instantanés ne nous semble pas une approche pratique. Pour cette raison, il est nécessaire d'augmenter le numéro de version dans les projets à chaque assemblage.

De plus, le développeur a parfois besoin de collecter sa propre branche d'une bibliothèque et de vérifier ses performances par rapport à toutes les dépendances, pour lesquelles toutes doivent changer manuellement la version.

Décision initiale

Avec des changements de version si fréquents et multiples, le processus au sein de CI veut être simplifié et automatisé. Ici, le plugin bien connu versions-maven-plugin vient à la rescousse - nous le connectons et l'exécutons

versions mvn -N: set -DnewVersion = 2.0.1

et le Maven fera tout comme il se doit: parcourir la hiérarchie de haut en bas, remplacer toutes les versions - la beauté! Il ne reste plus qu'à augmenter la pull-request, les collègues surveilleront les changements et vous pourrez rejoindre rapidement le coffre. Vite? Peu importe comment. Quelques centaines de pom.xml par revue, et cela ne compte pas 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 que dans le processus CI, les changements de version se produisent automatiquement avec un changement de fonctionnalité, et non en quelque sorte séparément.

De nouvelles fonctionnalités

Pendant un certain temps, nous nous sommes calmés et avons vécu en paix, jusqu'à ce que les gars du projet Maven Apache soient inclus dans maven, à partir de la version 3.5.0-beta-1, prise en charge des soi-disant «espaces réservés» des versions (espaces réservés). L'essence de ces substituts est que les variables $ {revision} , $ {sha1} et $ {changelist} sont utilisées dans pom.xml au lieu de spécifier la version du projet. Les valeurs de ces propriétés elles-mêmes sont définies soit dans l'élément < properties >, soit elles peuvent être définies via la propriété système

mvn -Drevision = 2.0.0 package propre

Les valeurs des propriétés système ont priorité sur les valeurs définies dans < propriétés >.

Le parent
<projet>
<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> Premier CI Friendly </name>
<version> $ {revision} $ {sha1} $ {changelist} </version>
...
<propriétés>
<revision> 1.3.1 </revision>
<changelist> -SNAPSHOT </changelist>
<sha1 />
</properties>
</project>

Descendant
<projet>
<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 créer la version 2.0.0-SNAPSHOT, utilisez simplement

mvn -Drevision = 2.0.0 package propre

Si vous voulez faire une version, alors mettez à zéro INSTANTANÉ

mvn -Dchangelist = package propre

* Les exemples ci-dessus sont extraits d'un article sur le site Web du projet Maven Apache

Une dure réalité

Tout est bon et sain, il est temps de ressentir un sentiment de satisfaction, mais non. Il s'avère que pour l'installation et le déploiement, cette méthode ne fonctionnera pas, car $ {revision} ne sera pas remplacé par sa valeur dans les descriptions des artefacts publiés dans le référentiel et maven ne comprendra pas de quoi il s'agit.

<parent>
<groupId> org.apache </groupId>
<artifactId> apache </artifactId>
<version> $ {revision} </version>
</parent>

La lumière au bout du tunnel

Nous devons chercher une solution au problème. La situation aurait pu être sauvée par un plugin flatten-maven . Ce plugin autorise toutes les variables dans pom, mais en même temps, il supprime une tonne d'autres informations qui ne sont nécessaires que lors de l'assemblage et ne sont pas nécessaires lors de l'importation d'artefacts publiés dans d'autres projets. De plus, le plugin «redresse» toutes les dépendances parent-enfant, et en conséquence, nous obtenons un pom plat, qui comprend tout ce dont vous avez besoin. L'inconvénient était qu'il coupait trop «trop», 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 ne sommes pas les seuls dans l'univers, et en août 2018, une pull-request a été créée sur le github dans le référentiel de plugins avec le désir de permettre de déterminer indépendamment comment «gâcher» pom.xml. Les développeurs ont écouté les voix des affligés, et déjà en décembre, avec la sortie de la nouvelle version 1.1.0, un nouveau mode resolCiFriendliesOnly est apparu dans le plugin flatten-maven, qui, comme jamais auparavant, laisse pom.xml tel quel, sauf pour l'élément <version> et permet $ {revision} , $ {sha1} et $ {changelist} .

Ajouter un plugin au projet

<plugins>
<plugin>
<groupId> org.codehaus.mojo </groupId>
<artifactId> plugin-flatten-maven </artifactId>
<version> 1.1.0 </version>
<configuration>
<updatePomFile> true </updatePomFile>
<flattenMode> resolCiFriendliesOnly </flattenMode>
</configuration>
<exécutions>
<exécution>
<id> aplatir </id>
<phase> process-resources </phase>
<objectifs>
<goal> aplatir </goal>
</goals>
</execution>
<exécution>
<id> flatten.clean </id>
<phase> nettoyer </phase>
<objectifs>
<goal> propre </goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>


C'est fait!

Fin heureuse

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 une seule racine pom.xml . Ce ne sont pas cent ou deux de ces fichiers avec le même changement qui entrent dans la revue, mais un. Eh bien, il n'est pas nécessaire d'utiliser le plugin versions-maven .