08 February 2021
La réflexion se fait sur la base de l'article suivant :
L'utilisation de numéro de versions à la main est problématique dans un contexte d'automatisation, or “Every build is a potential release”.
L'article pointe également le fait que le maven-release-plugin pose des problème en générant trois cycles et autant de commits.
La préconisation est donc d'utiliser le hash du commit pour nommer chaque artefact. Pour ce faire, utilisation de git-commit-id-plugin. Ce plugin demande d'ajouter une configuration d'execution.
La suite de l'article montre comment générer l'artefact docker depuis maven ave fabric8, mais avec le commentaire postérieur qu'il serait plus malin de le faire avec jib en 2019.
Enfin, comme c'est l'artefact docker qui est généré, l'article propose d'inhiber le fait de pousser les .jar dans les repository locaux.
Pour le développement du SI-DTP avec les outils de CI mis en place sur gitlab avec MMA, le problème est le fait qu'il n'y a pas de réutilisation d'artefacts java. Cela entraine plusieurs problèmes :
Il faut distinguer deux cas, celui des produits "finis" qui font l'objet d'un service conteneurisé, et les libs, qui doivent être réutilisés pour la création des premiers.
Je rajoute la section suivante dans plugins :
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>2.2.4</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<dateFormat>yyyyMMdd.HH'h'mm</dateFormat><!-- human-readable part of the version number -->
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
<generateGitPropertiesFile>false</generateGitPropertiesFile><!-- somehow necessary. otherwise the variables are not available in the pom -->
</configuration>
</plugin>
Et en tête de pom cela devient :
<version>0.0.3+${version.number}</version>
<properties>
<version.number>${git.commit.time}.${git.commit.id.abbrev}</version.number>
</properties>
Lorsque l'on fait un mvn package
[...]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ dicranum-api-client ---
[INFO] Building jar: C:\Users\hnl-bis\workspace\dicranum-api-client\target\dicranum-api-client-0.0.3+20210210.19h07.c272652.jar
[...]
OK
Par contre, lorsque je fais mvn install, les variables ne sont pas substituées.
[...]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ dicranum-api-client ---
[INFO] Installing C:\Users\hnl-bis\workspace\dicranum-api-client\target\dicranum-api-client-0.0.3+20210210.19h07.c272652.jar to C:\Users\hnl-bis\.m2\repository\fr\cst\rd\cannes2020\dicranum-api-client\0.0.3+${git.commit.time}.${git.commit.id.abbrev}\dicranum-api-client-0.0.3+${git.commit.time}.${git.commit.id.abbrev}.jar
[INFO] Installing C:\Users\hnl-bis\workspace\dicranum-api-client\pom.xml to C:\Users\hnl-bis\.m2\repository\fr\cst\rd\cannes2020\dicranum-api-client\0.0.3+${git.commit.time}.${git.commit.id.abbrev}\dicranum-api-client-0.0.3+${git.commit.time}.${git.commit.id.abbrev}.pom
[...]
En parcourant plusieurs articles de blog, ou sur stackoverflow le problème semble connu.
Comme dirait le poète, it's a feature, not a bug. Un des points importants est que le pom est déployé sur le repository et comprends le numéro de version. S'il n'est pas codé en dur, cela pose des problèmes pour les autres développements maven qui vont dépendre de ce pom.
La piste proposée dans l'article suivant, est de filtrer le pom au déploiement...