Il y a 9 ans -
Temps de lecture 15 minutes
La notion de BOM avec Maven
Maven est une solution de gestion de production de projets mature et connue du plus grand nombre. Sa dernière release majeure (version 3.0) date de 2010 et depuis, peu de grandes nouveautés ont été ajoutées (nous en sommes à la release 3.1.1).
Dans cet article, nous allons revenir sur une fonctionnalité de Maven ancienne mais moins utilisée, la notion de BOM ou Bill Of Materials. Ce principe remonte à la release 2.0.9 de Maven d’avril 2008 et s’appuie sur l’ajout du scope import.
Scope import
Revenons tout d’abord sur le scope import de Maven. Les scopes dans Maven permettent d’agir sur la portée de vos dépendances. Ainsi, par exemple, le scope test permet l’utilisation des dépendances uniquement lors du déroulement des tests.
Le scope import est utilisable seulement dans la section dependencyManagement du pom.xml et pour une dépendance de type pom. À la lecture du pom.xml, Maven va remplacer la dépendance import par toute la section dependencyManagement de cette dépendance.
Pour mieux comprendre ce principe, voici un exemple concret. Prenons un pom.xml A comme suit (remarquez la valeur "pom" de la balise packaging):
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.xebia.blog</groupId> <artifactId>pomA</artifactId> <version>1</version> <packaging>pom</packaging> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>4.0.1.RELEASE</version> </dependency> </dependencies> </dependencyManagement> </project>
Puis un pom.xml B utilisant le scope import:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.xebia.blog</groupId> <artifactId>pomB</artifactId> <version>1</version> <packaging>jar</packaging> <dependencyManagement> <dependencies> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>pomA</artifactId> <version>1</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> </project>
Maven en déduira à la lecture du pom.xml B un pom comme suit:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.xebia.blog</groupId> <artifactId>pomB</artifactId> <version>1</version> <packaging>jar</packaging> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>4.0.1.RELEASE</version> </dependency> </dependencies> </dependencyManagement> </project>
Remarquez le type pom de la dépendance sur l’artifact pomA. Sans ce type, vous ne pourrez pas compiler vos projets.
Voilà comment fonctionne le scope import de Maven. L’intérêt de celui-ci peut ne pas vous sauter aux yeux de prime abord. Nous allons donc voir un de ses intérêts avec les BOM Maven.
Principe du BOM Maven
Concrètement, nous avons vu que le scope import permet d’importer des dependencyManagements dans un autre pom. Le principe du BOM est d’exploiter cette capacité.
Nous allons définir dans le BOM, qui n’est rien d’autre qu’un pom avec seulement une section dependencyManagement, toutes les versions des dépendances que nous voulons utiliser dans nos projets. Le BOM est donc une sorte d’annuaire de versions de toutes les dépendances, ce qui permet de ne plus s’occuper des versions dans le reste de vos projets.
En effet, avec Maven, si vous définissez une dépendance dans la section dependencyManagement, vous n’êtes plus obligé de déclarer la version dans la déclaration réelle de vos dépendances (section dependencies du pom). Ainsi, pour notre exemple ci-dessus avec la dépendance Spring, vous pouvez déclarer les dépendances comme suit:
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> </dependency>
Maven saura automatiquement qu’il s’agit de la version 4.0.1.RELEASE.
Avantage de la notion de BOM
La définition de version est tout à fait possible avec un pom parent classique. Le parent définit les versions dans le dependencyManagement de la même façon que le BOM.
Ce système est très pratique dans le cadre d’un petit projet. Par petit, je parle du nombre de modules liés et de la complexité des dépendances inter-projets.
Mais sur un gros projet, voire un ensemble de projets, cela peut vite devenir un casse tête.
Alors quel est l’avantage du BOM ?
Un pom.xml ne peut avoir qu’un seul et unique parent, ce qui vous oblige à déclarer TOUTES les versions de vos dépendances dans le même parent.
Si vous voulez découper proprement vos versions (le front d’un côté, le back de l’autre par exemple), ce n’est pas possible. Un parent peut bien sûr avoir lui-même un parent et ainsi de suite, mais cela peut vite devenir compliqué à gérer.
Par exemple, comment définir qui est le parent de qui ? Le front est-il le parent du back ou l’inverse ? Si vous releasez un parent, vous serez obligé de releaser ces fils pour pouvoir prendre en compte la nouvelle version alors que ceux-ci n’ont pas forcément bougé.
Bref, l’utilisation abusive de parents peut vite devenir problématique. Le BOM Maven va nous permettre de régler ça.
En effet le BOM agit comme une dépendance classique, vous pouvez donc en importer autant que vous le souhaitez dans un pom.xml
Ainsi, vous pouvez décider d’avoir un BOM front (avec votre framework front favori par exemple), un BOM back (avec hibernate) et un autre BOM avec des dépendances autres (Spring, …).
Ensuite, nous pouvons imaginer avoir un pom.xml comme ceci:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.xebia.blog</groupId> <artifactId>pomB</artifactId> <version>1</version> <packaging>pom</packaging> <dependencyManagement> <dependencies> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>bom-back</artifactId> <version>1</version> <scope>import</scope> <type>pom</type> </dependency> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>bom-spring</artifactId> <version>1</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> </project>
Grâce à ce système de BOM, vous pouvez centraliser vos versions externes à un seul endroit. Si Spring sort une nouvelle version, seule la personne s’occupant des BOMs devra les mettre à jour. Ensuite, tous les projets dépendants n’ont pas besoin de savoir que Spring a évolué.
Pour ces projets, seule la version du BOM a évolué, et il suffit de l’impacter dans les pom.xml du projet.
Exemple concret : mise en place d’une bibliothèque de composants modulaires
Après la théorie, place à la pratique.
Cet exemple est tiré d’une expérience réelle. Avant de voir le code, voici le contexte et l’explication du choix du BOM.
L’équipe dans laquelle je travaillais a pour objectif de maintenir un ensemble de produits d’assurances et de pouvoir rapidement en développer de nouveaux.
Chaque produit est une webapp distincte mais doit avoir une ergonomie identique et une base technique identique.
Ainsi pour tous les composants front (mais également techniques), il a été décidé de mettre en place une bibliothèque maison proposant un ensemble de composants réutilisables. Un exemple de composant peut être un formulaire de saisie d’adresse normalisée par la Poste.
Les contraintes de ce framework sont :
- Forte modularité pour permettre des mises à jour rapides
- Permettre l’ajout de nouveaux composants facilement
- Faciliter l’intégration dans les produits finaux en masquant au maximum la complexité de la bibliothèque
Pourquoi choisir le BOM dans la conception de la bibliothèque ?
Avant de s’orienter vers le BOM, nous avons étudié deux autres pistes plus communes que nous avons rejetées:
La release monolithique. Avec cette option, il n’y a qu’un seul trunk svn contenant l’ensemble des composants. Un pom parent porte le versionning de tous ces derniers. Ils sont releasés ensemble et évoluent donc de version ensemble.
Cette option est rejetée : tous les composants évoluent en même temps, ce qui empêche une maintenance facile et rapide. La bibliothèque propose plus d’une quarantaine de briques, la release prend donc du temps.
De plus, un développeur ne peut facilement toucher un composant. En effet, s’il commite ses modifications alors qu’une maintenance doit avoir lieu, ces dernières seront embarquées de manière non voulue (et potentiellement non visible).
Enfin le pom parent oblige les produits à l’utiliser, ce qui peut poser des problèmes.
La multiplication des trunks svn. Dans notre cas, étant donné que la release monolithique n’est pas une bonne option, pourquoi ne pas avoir un trunk svn par composant ? Cela élimine le problème du temps des releases et du pom parent.
Chaque composant étant releasé indépendamment, chaque produit doit donc connaitre l’ensemble des versions des composants, ce qui peut devenir complexe.
Nous voila donc arrivé à la solution du BOM. Comme vu plus haut, le BOM agit comme une dépendance classique, éliminant la contrainte liée au parent. Ensuite le BOM va agir comme un index de bibliothèque en portant l’ensemble des versions des différents composants. Ainsi, les produits ont besoin de connaitre uniquement la version du BOM et non l’ensemble des versions, masquant la complexité de la bibliothèque. Enfin l’ensemble est dans une seule structure svn, ce qui facilite la gestion et l’ajout de nouveaux composants (un répertoire à créer, et une version à ajouter dans le BOM).
Voyons maintenant comment créer cet index.
Tout d’abord commençons par la structure de répertoire. Comme dit plus haut, tout est dans la même structure svn, nous avons donc une structure simple:
|___bom-composant |___composantA |___composantB |___composantC |pom.xml
Je ne rentrerai pas dans les détails des composants, vous pouvez mettre ce que vous voulez dedans.
L’intérêt repose sur le bom-composant. C’est lui qui va être l’index de notre bibliothèque.
Ce répertoire ne contient qu’un seul pom comme suit:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fr.xebia.blog</groupId> <artifactId>bom-composant</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <name>${project.artifactId}</name> <dependencyManagement> <dependencies> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantA</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantB</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantC</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> </dependencyManagement> </project>
Ce pom.xml contient uniquement une section dependencyManagement, où vous trouverez la version de toutes les briques. Au départ, elles sont toutes en SNAPSHOT, mais cela va vite bouger.
Pour le moment rien de compliqué. Toute la subtilité de ce schéma réside dans le pom reactor de la bibliothèque (le pom à la racine) et la commande de release.
Voici ce pom un peu plus long que les précédents:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <artifactId>reactor</artifactId> <version>1.9-SNAPSHOT</version> <packaging>pom</packaging> <name>${project.artifactId}</name> <profiles> <profile> <id>composantA</id> <modules> <module>composantA</module> <module>bom-composant</module> </modules> </profile> <profile> <id>composantB</id> <modules> <module>composantB</module> <module>bom-composant</module> </modules> </profile> <profile> <id>composantC</id> <modules> <module>composantC</module> <module>bom-composant</module> </modules> </profile> </profiles> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.4.2</version> <configuration> <updateDependencies>false</updateDependencies> </configuration> </plugin> </plugins> </build> </project>
Intéressons-nous d’abord au bloc profiles. Aucun profil actif par défaut. Ce comportement est voulu afin d’éviter l’abus de compilation complète à tout va (et perdre l’avantage de la modularité).
Chaque composant possède donc son profil d’activation afin de le compiler. Les profils contiennent tous le BOM, afin que ce dernier soit toujours à jour en cas de compilation.
Ainsi la commande Maven pour compiler un composant devient la suivante:
mvn clean install -PcomposantA
Voyons maintenant la configuration du plugin release. Veillez à bien prendre la dernière version (2.4.2), l’option utilisée ne fonctionnant pas dans les versions précédant la 2.3 (pourtant intégrée depuis la 2.0).
Dans la configuration, on ajoute l’option updateDependencies en la mettant à false. Cette option va permettre au BOM de fixer les versions qu’il porte. Sans cette option, au moment de la release, les versions des composants dans le BOM vont automatiquement passer à la version de développement supérieure.
Par exemple, lors de la première release, la version du composantA va passer de 1.0-SNAPSHOT à 1.1-SNAPSHOT. Ceci nous empêcherait de fixer nos versions.
Avec l’option activée, le composantA restera figé à 1.0.
C’est cela qui va nous permettre de modulariser notre bibliothèque. Si pour une raison ou une autre vous devez modifier le composantA, il suffit de passer la version à 1.1-SNAPSHOT dans le BOM, faire la modification et lancer la commande suivante pour fixer la version:
mvn release:prepare -PcomposantA release:perform
Le composantA est maintenant en 1.1 dans votre index de bibliothèque et les deux autres composants n’ont pas bougé.
Enfin pour utiliser l’index dans une webapp, il suffit de tirer la dépendance BOM comme suit:
<dependencyManagement> <dependencies> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>bom-composant</artifactId> <version>1.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
Puis d’indiquer dans vos dépendances celle que vous souhaitez utiliser (notez l’absence de version dans ces dépendances).
<dependencies> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantA</artifactId> </dependency> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantB</artifactId> </dependency> <dependency> <groupId>fr.xebia.blog</groupId> <artifactId>composantC</artifactId> </dependency> </dependencies>
Vos webapps sont maintenant capables de bénéficier des composants sans se préoccuper des versions et peuvent bénéficier rapidement des correctifs de la bibliothèque en mettant à jour uniquement la version du BOM.
Si vous souhaitez voir l’exemple complet de code en action, je vous invite à voir les sources sur le github suivant: https://github.com/RNiveau/article-bom-maven
Voilà pour la notion de BOM avec un exemple concret. Ce système de bibliothèque permet de pouvoir modulariser vos frameworks tout en gardant une complexité faible pour les produits/webapp finaux. De plus, contrairement aux pom parents classiques, il est tout à fait possible d’imaginer tirer plusieurs BOM afin de bénéficier de plusieurs frameworks différents.
Le système de BOM peut être plus coûteux à mettre en place qu’un système plus classique de parents, mais sur des projets complexes en terme de dépendances ou sur un ensemble de projets, ce système s’avère être beaucoup plus évolutif et simple à maintenir.
Commentaire
19 réponses pour " La notion de BOM avec Maven "
Published by Daco , Il y a 9 ans
Excellent article. Je ne connaissais pas ce principe de BOM, je vais regarder de plus près et voir pour remplacer notre gestion des dépendancesavec l’héritage classique dans un corporate.
Merci
Published by Arnaud Héritier , Il y a 9 ans
Salut,
2 petites remarques :
* « nous en sommes à la release 3.1.1 » => La version 3.2.1 est sortie il y a quelques jours :-) http://maven.apache.org/docs/3.2.1/release-notes.html Au programme les exclusions avec wilcards …
* Un point à faire très attention avec les BOMs et d’une manière générale avec le dependencyManagement : Il n’est pas transitif. Si PRJ_A dépend (directement ou par transitivité) de toto 1.2.3 mais utilise le dependencyManagement pour forcer l’utilisation de sa version 4.5.6 alors si PRJ_B dépend de PRJ_A il verra toto 1.2.3 mais pas 4.5.6 (sauf si lui aussi change la version dans son dependencyManagement directement ou par import).
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Effectivement, je n’ai pas vérifier entre le début de la rédaction de l’article et sa publication si une release était sortie, j’aurais dû :). Les nouveautés semblent intéressantes en tout cas.
Pour la précision sur la transitivité, c’est en effet un détail important car ça peut générer des comportements non voulus et parfois compliqués à résoudre.
Published by guest , Il y a 9 ans
maven n’est qu’un outil de build.
son utilisation se doit d’être neutre.
Imposer un pom corporate ou un ‘bom’ n’est pas dans l’esprit de maven;
ces méthodes imposent un ‘socle’ qui se doit d’être maintenu; ce coût est toujours omis.
L’utilisation du ‘dependencymanagement’ au niveau du pom parent correspondant au produit – et du ‘trunk’ associé – est la solution la plus pérenne, même si les composants du produit ont des versions différenter.
Merci pour l’article.
Published by Aurélien , Il y a 9 ans
Bonjour,
Merci pour cet excellent article !
J’ai trouvé cet article qui traite du même sujet : http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html. Par contre j’étais étonné que ce dernier n’indique pas d’utiliser le scope import.
Est ce que selon vous il existe une différence entre ces deux méthodes en terme de transitivité par exemple ?
D’avance merci pour votre éventuel éclairage.
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Oui il y a une différence importante entre les 2 exemples.
Le BOM s’appuie sur le dependencyManagement. Sans scope import, cette section est non prise en compte lors de l’utilisation de la dépendance et le BOM devient donc inutile.
Dans l’article que vous donnez, l’auteur s’appuie sur la section dependencies. Sa dépendance regroupe un ensemble de jars dans un pom.xml (d’où le type pom car il n’y a pas de source dans son projet) ce qui lui permet de factorisé les dépendances à un seul endroit. Toutefois, lorsqu’il tire cette dépendance (persistence-deps), il force l’utilisation de l’ensemble des jars indiqués qu’ils soient utilisés ou non.
Les deux techniques peuvent d’ailleurs se cumuler pour avoir une gestion encore plus fine des dépendances.
Published by Aldric , Il y a 9 ans
Bonsoir,
Merci pour cette excellent article!
je suis en train de tester cette solution,
spécialement lorsqu’un composant dépend d’un autre.
J’ai repris votre exemple et en faisant dépendre le composantB du composantA.
J’ai alors l’erreur suivante lors de la construction du composantB :
The project fr.xebia.blog:composantB:1.7-SNAPSHOT has 1 error
‘dependencies.dependency.version’ for fr.xebia.blog:composantA:jar is missing.
Est-ce que vous avez rencontré ce problème ?
Et si oui, est-ce que vous avez trouvé une solution de contournement ?
Merci d’avance
Aldric
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Les composantA et B sont des composants du bom, ils ne bénéficient donc pas de ce dernier. Seules les webapp (ou autres projets) qui importeront les boms en bénéficieront. Vous devez donc soit créer un pom-parent pour qui relient vos composants entre eux (mais vous risquez de casser la modularité), soit vous déclarez la version de composantA dans B.
Published by Clément HELIOU , Il y a 9 ans
Bonjour Romain et merci pour cet article, bien écrit et très intéressant.
Je suis curieux d’avoir votre avis quand au message (critique) laissé par le visiteur anonyme du 28/02 dernier.
Bien à vous,
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Je ne suis pas d’accord sur le faite que le BOM n’est pas dans l’esprit de Maven car ce principe est justement évoqué sur le site officiel de Maven.
Par contre je rejoins cet avis sur le cout de la maintenance du socle. Le BOM permet de centraliser les versions, mais cela sous entends qu’il faut maintenir ce BOM dans le temps, ce qui, forcement, implique un cout.
Published by Guest , Il y a 9 ans
A la relecture de ce billet, et de mon commentaire du 28/02, je souhaite modérer mon propos et préciser.
J’ai dit : « Imposer un pom corporate ou un ‘bom’ n’est pas dans l’esprit de maven ». C’est effectivement faux, puisque documenté dans http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html .
Je trouve aujourd’hui la formulation « esprit de Maven » maladroite, à côté de la plaque; l’idée était simplement de mettre en garde contre l’idée de ‘socle’ figeant fortement le développement des produits d’une entreprise, à moins de le maintenir, d’en assumer le coût, et de communiquer aux équipes.
Ce qui me choque le plus à la relecture, c’est l’importance que j’ai donnée au ‘dependencyManagement’ !
Si la centralisation des versions de plugins utilisés au plus haut niveau via ‘pluginManagement’ est nécessaire,
les dépendances ne doivent pas être centralisées, à moins d’être de bas niveau de type driver database (contraintes d’exploitation).
Rien de doit empêcher différents modules du même produit d’utiliser des versions différentes de la même bibliothèque, notamment sur des applications de type ‘legacy’.
En espérant que cette opinion alimente la réflexion.
Published by Olivier , Il y a 9 ans
Salut,
Petite question annexe, comment faire avec le système de BOM pour gérer les plugins ? Dans le cas où on a pas mal de modules, livrés et versionnés indépendamment en utilisant le mécanisme des BOM, on s’affranchit des parents. Mais si on a des ensembles de modules qui utilisent une même configuration de leurs plugins, on fait comment ? Il y a une astuce ou on repasse avec un parent commun pour ces ensembles de modules ?
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Malheureusement, il n’est pas possible de faire des BOMs de plugins. J’ai d’ailleurs ouvert un Jira Maven pour ça (http://jira.codehaus.org/browse/MNG-5588).
Il est donc obligatoire de passer par un parent à l’heure actuelle. Il est possible de cumuler les deux techniques mais en contrepartie, ça complique le système.
D’expérience, un parent avec les plugins + les BOMs, c’est possible, plus ça devient vraiment complexe à gérer.
Published by Olivier , Il y a 9 ans
Yes. Pour ce qui est de la complexité, j’avais remarqué ;)
En fait, je suis sur le dév. d’un socle. Ma problématique personnelle est de gérée les dépendances de plugins et de librairies tierces pour mon socle, est de fournir des BOM à mes « clients » pour qu’ils n’aient pas besoin de se poser la question des versions de n librairies qu’on leur fournit. Donc dans mon cas, je peux me passer du principe de BOM, mais ça implique que toutes les librairies que je fournit ont le même numéro de version… D’où l’utilisation d’un parent pour mes besoins « interne » et des BOM pour mes livraisons.
Merci en tout. Et je vais suivre l’état d’avancement du Jira chez Codehaus.
Published by Guest , Il y a 9 ans
Une proposition de solution au précédent message : un ‘pom de distribution’, lui aussi versionné ?
Published by Olivier , Il y a 9 ans
Re,
La question des tags se pose quand même dans cette solution.
Si je résume, on a un trunk, en dessous n modules indépendant et donc livrés indépendamment et leurs versions gérées à travers un BOM.
Donc, la version du parent (si on utilise en toute logique le maven release plugin) va évoluer à chaque livraison d’un module. DOnc pour chaque module on a un tag.
Mais comment s’y retrouve-t-on au milieu de tous ces tags ? Comment savoir que la version 1.18 correspond à une évol du composant B ? Quand je regarde mon SCM… je n’ai pas cette information. Alors qu’in fine, avec plusieurs trunk, je l’ai. Je connais la livraison de chaque trunk, donc je sais ce qui est modifié/impacté par une livraison. Là, j’ai un tag, qui ne concerne potentiellement qu’un seul composant et pourtant tout le trunk qui est tagué sans information précise sur les modifs, visible rapidement/facilement.
Une méthodologie permet de résoudre ce problème ? Des noms autres pour les tags, plutôt que des numéros de versions seuls ? Faire des releases/tags partiels par composant ? Autre chose ?
Merci,
Olivier.
Published by Romain Niveau , Il y a 9 ans
Bonjour,
Tu touches la une des problématiques de cette technique. Oui le parent évolue à chaque release et oui c’est à toi de savoir ce que contient un tag.
Le parent est sans réel importance puisque c’est la version du bom qui compte.
Mais pour le tag, effectivement, tu ne sais pas rapidement ce qui a changer en regardant svn.
Tu ne peux pas faire de release partielle avec cette méthode car tu casseras le système en entier (la release « partielle » doit passer par l’utilisation des profiles)
Published by Guest , Il y a 9 ans
Décidément, ce sujet va devenir un joli troll ;-) mais intéressant.
Olivier, je précise mon message précédent. je décris la solution retenue pour un client qui tenait absolument à pouvoir faire des releases ‘partielles’ de ses x composants (x modules maven avec chacun son ‘trunk’) mais qui s’arrachait les cheveux pour maintenir ses correspondances de versions lors de livraisons ‘globales’.
Une solution consiste à écrire – et maintenir – un pom parent/englobant/de plus haut niveau (avec lui aussi son ‘trunk’ associé) qui explicite les versions des modules qu’il agrège.
Je crois que le terme qui convient le mieux est bien ‘pom de distribution’.
Published by Peter MOUEZA , Il y a 8 ans
Très bon article!
Merci.