Hi, I can't see any text to translate.

Question

Si vous utilisez Maven2 en tant que système de construction pour un projet contenant de nombreux artefacts avec le même numéro de version, vous avez la version de la construction résultante dispersée dans tous les pom.xml. Dans beaucoup d'entre eux même deux fois - dans la balise de version de l'artefact lui-même et dans la balise de version du parent. Ainsi, vous devez modifier et vérifier de nouvelles versions de tous les pom.xml à chaque changement de version. C'est quelque peu ennuyeux, surtout si vous devez coder pour plusieurs corrections de bogues et une version de développement en parallèle. Y a-t-il un moyen de contourner cela?

ÉCLAIRCISSEMENT: Ma question concerne les nombreuses versions de chaque pom.xml que vous obtenez au fil du temps dans votre système de contrôle de source qui ne diffèrent que par le numéro de version du pom et/ou le numéro de version du pom parent. Idéalement, vous ne devriez avoir à modifier le pom que lorsque vous ajoutez une dépendance ou quelque chose.

Par exemple, vous avez un projet avec les artefacts foo-pom (le pom parent de tous), foobar-jar, foobaz-jar et foo-war. Dans la première version, la version est 1.0 - qui apparaît dans chaque pom.xml. Dans la deuxième version, la version est 1.1 - qui apparaît à nouveau dans chaque pom.xml. Vous devez donc modifier chaque pom.xml - ce qui est ennuyeux si vous publiez aussi souvent que vous le devriez.

MISE À JOUR: Si vous pensez que c'est important : le fait de ne pas avoir à spécifier la version du parent est déjà en cours de discussion. Veuillez vous rendre sur l'issue Maven JIRA et voter pour qu'il soit plus remarqué et plus susceptible d'être ajouté comme une amélioration dans une prochaine version. Vous devez créer/avoir un login JIRA pour cela.

Il y a une autre question Stackoverflow qui traite essentiellement du même problème.

Answer 1

Il y a un autre fil StackOverflow qui traite également de ce sujet que vous voudrez peut-être consulter.

En résumé, le fait de ne pas avoir à spécifier la version parent lors de l'utilisation de l'héritage est déjà en cours de réflexion. Veuillez vous rendre sur JIRA et lui donner un coup de pouce en votant pour qu'il soit plus remarqué et plus susceptible d'être ajouté comme amélioration dans une prochaine version.

Answer 2

J'ai rencontré des problèmes similaires en travaillant sur un système important construit avec Maven 2.

À mon avis, l'inconvénient de la structure multi-modules typique est que tous les modules doivent partager la même version. C'est en effet ennuyeux : même si votre prochaine version ne consiste qu'en une correction de bug dans foobar-jar, vous devez changer la version globale partout (manuellement ou avec maven-release-plugin) et créer une nouvelle version de chaque composant. Dans mon cas, j'ai construit diverses applications WAR/EAR, donc mon client me demanderait pourquoi j'ai livré une nouvelle version à la fois d'app1 et d'app2, alors que seule app1 était censée être impactée.

L'approche opposée consiste à gérer chaque composant comme un projet indépendant, avec sa propre version indépendante. Cela est plus flexible car il permet des versions partielles, mais vous devez maintenant suivre toutes ces versions manuellement (savoir quelles versions composeront votre prochaine livraison, s'assurer que les dépendances internes sont consistantes, etc.). Cela peut rapidement devenir un cauchemar dans une grande application.

J'ai longtemps réfléchi à une façon de combiner les deux approches : la flexibilité des versions indépendantes, sans abandonner la cohérence globale du système. J'ai essayé la même approche que romaintaz, et j'ai rencontré le même problème. En fin de compte, j'ai eu cette idée : http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html.

Considérez cela comme 'expérimental', car je n'ai pas eu la chance de l'essayer en direct à la fin (pour des raisons non techniques). Mais je pense que cela fonctionnerait.

Answer 3

Sur mon projet, j'ai un tel problème. Pour réduire le nombre de versions que je définis dans mon fichier pom.xml parent, je définis certaines propriétés, qui correspondent aux versions de chaque module :

    1.0.0

    ${project-version}

    1.0.1
    ...

Et ensuite, dans le pom.xml de chaque module, j'utilise ces propriétés. Le problème est que je dois clairement entrer la version du parent dans ce pom.xml. Par exemple, dans mon business pom.xml, j'ai :

  4.0.0

    mon.projet
    parent
    1.0.0

  ...

      mon.projet
      project-persistence
      ${project-persistence-version}

Cependant, je vous suggère vraiment de jeter un œil au plugin de release qui se chargera de modifier tous les numéros de version pour vous.

Answer 4

Est-ce que cet article fournit une solution à votre problème ?

L'idée est de déclarer le numéro de version pour l'ensemble du projet en tant que propriété, nommément "aversion" (jeu de mots intentionnel), dans le pom parent. Le numéro de version du pom parent lui-même peut être n'importe quoi tant qu'il se termine par "SNAPSHOT".

La version des modules enfants est spécifiée via la propriété ${aversion}. La référence des enfants à la version de leur parent est codée en dur. Cependant, puisque la version du pom parent est un SNAPSHOT, les modules enfants verront les modifications apportées au pom parent. En particulier, si le pom parent modifie la valeur de ${aversion}, les enfants verront le changement.

Non pas une solution parfaite selon les commentaires.

Et le plugin de publication ne résout pas le vrai problème : la fusion.
Avoir d'innombrables copies du numéro de version partout signifie beaucoup de conflits lors de la réunification des branches.

Note :

Avec Maven 2.0.9 (le dernier - avril 2008) j'ai simplement omis l'élément de version des modules individuels car ils hériteront de la version de leur parent. Cela fonctionne également avec le groupId si vos modules ont le même groupId que leur parent.

Answer 5

Ceci est une idée pour une extension possible de Maven qui résoudrait le problème. Actuellement, vous devez écrire une version de l'artefact et du pom parent dans le fichier pom.xml. Il existe déjà un moyen de donner un emplacement absolu pour le pom parent :

    org.codehaus.mojo
    my-parent
    2.0
    ../my-parent

Si vous autorisez l'omission à la fois de la version du parent et de ce pom si Maven est capable d'accéder au pom parent par le chemin relatif, vous avez terminé. La version n'est mentionnée que dans le pom parent et nulle part ailleurs.