Discussion :

[rt15]

(Re)bonjour,

Nous sommes en train de mettre en place une procédure d'intégration continue Maven (2.0.9) + Hudson. Nous avons de nombreux modules.

Selon la doctrine de l'intégration continue, sauf erreur, il faut compiler (Et tester) très régulièrement la dernière version du source.

En conséquence, si le module "voiture" utilise le module "roue", il faudrait recompiler "roue", puis "voiture", en précisant à "voiture" d'utiliser "roue" en dernière version.

En dernière version -> Range. C'est du moins la seule méthode que je connaisse. J'ai vaguement entendu parler d'un LATEST éventuellement, mais rien de probant sur le sujet.

Donc ça me donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
				<dependency>
					<groupId>peurault</groupId>
					<artifactId>roue</artifactId>
					<version>[12.0.1,)</version>
				</dependency>

Bien, maintenant, il faudrait que je livre une "voiture" 4.0.4. Premier problème, il me semble que le plugin release va me jetter car la dernière version de "roue" est un SNAPSHOT. Mais même en admettant que la dernière version soit une release, la 14.0.0 par exemple...

15 mois plus tard, les clients à qui j'ai livré une "voiture" 4.0.4 se plaignent car elle a une fuite d'huile. Il faut que je reconstruise une 4.0.4 pour voir d'où vient le problème. Je descends le source svn de "voiture" tagué en 4.0.4. Problème, dans mon pom, il y avait à l'époque (Et ça n'a pas changé d'ailleurs) : "roue" -> [12.0.1,).

Bilan, selon maven, la version de roue à utiliser avec ma "voiture" 4.0.4 est la dernière version qui est actuellement la 16.0.0. Mais manque de chance, il n'y a pas du tout compatibilité descendante du côté de mon module "roue" : je ne peux pas monter une "roue" 16.0.0 sur une 4.0.4.

Et je n'ai aucun moyen de savoir que j'ai livré des "roues" 14.0.0 avec mes 4.0.4. Cela pouvait être des 12.0.1, des 12.0.2, etc... Bref je vais avoir beaucoup de mal à corriger la fuite d'huile...

D'où ma question, sauriez vous comment s'arranger pour que ce soit toujours la dernière version qui soit utilisée, tout en ayant la capacité de se souvenir de la version utilisée pour telle ou telle livraison ? Mise à jour manuelle des poms (Pas automatisé donc source d'erreur, long...) ? Mise à jour automatique des poms (Difficile, il faut déterminer la dernière version de toutes les dépendances...) ? Autre chose ?

Merci d'avance de vos réflexions sur le sujet.

[lordseth0]

Bonjour,

Pour ma part, lors d'une release, nous appliquons ce qui est écris dans le paragraphe 'reproducibility' du lien que tu donnes, à savoir, enlever les ranges pour fixer une version (relativement rapide si tu mets les versions comme propriétés) et ce pom est taggé comme le pom de release. cela permet d'avoir l'historique.
Si il y a une meilleure méthode, je suis évidemment preneur.

[rt15]

Ah oui, j'avais pas vu ça.

Ca m'a l'air vraiment bien, surtout qu'on dirait que l'on peut générer le release-pom.xml !

Grand merci à toi, tu nous enlèves une belle épine du pied.

[aheritier]

Pour simplifier la résolution des ranges avant la release vous pouvez utiliser ce plugin : http://mojo.codehaus.org/versions-ma...ve-ranges.html