J'approsse la longueur de ce poteau, mais j'ai eu du mal à le rendre plus concis sans présenter la photo. J'ai récemment hérité du travail de Build-Master pour un projet multi-module Maven 3.0. Le problème est que la structure du projet / des modules est une catastrophe. D'après la façon dont les choses sont actuellement stockées dans le contrôle de la source (nous utilisons RTC) à la structure POM des modules, je me déchire les cheveux en essayant d'obtenir un cycle de construction complète terminé à chaque fois.
comme une hiérarchie de projet va, Tous les modules sont stockés "plat"; C'est-à-dire: tout est au même niveau. J'ai un parent pom, et tous les modules dépendent du parent. Cependant, le parent est au même niveau que tous mes autres modules. P>
ex: p> Le parent pom définit tous les modules nécessaires pour construire le Projet, ainsi que des propriétés de propriétés pour les numéros de version d'artefact utilisés dans les différents sous-modules: P> <parent>
<groupId>com.cws.cs.lendingsimulationservice</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.6</version>
</parent>
3 Réponses :
Si vous publiez votre POM, vous devrez publier des mises à jour, mais vous n'avez pas besoin de modifier les versions POM à la main - vous pouvez mettre à jour les versions automatiquement à l'aide du plug-in versions ou du plugin de version. J'ai tendance à préférer le plugin de sortie car il va s'engager à SCM pour vous aussi.
mvn release:prepare release:perform
Je n'ai pas utilisé le plugin de sortie depuis un moment, mais je ne comprends pas comment cela résoudra mon problème lorsque j'ai besoin de faire progresser un module individuel vers une nouvelle version. Si le module3 a besoin de mise à jour (passe de 1,1 à 1.2-instantané), et le module1 dépend du module3, puis je mettez à jour le module3 pom, la propriété parent-pom, la version parent-POM, la version parente de module3 et enfin Module1 Version parent et Module1. Comment le plugin de version peut-il accomplir tout cela pour moi? Notez que Module2 n'est pas tenu de changer quoi que ce soit à ce stade.
Le plugin versions devrait pouvoir mettre à jour les dépendances pour vous, puis vous pouvez simplement valider et déployer les nouveaux artefacts.
La première chose que je recommande vraiment est de restructurer les dossiers de projets ... ce que signifie que le dossier de projets représente la structure qui signifie pas em> aplaticez la structure. <parent>
<groupId>com.cws.cs.lendingsimulationservice</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.6</version>
</parent>
<artifactId>module-1</artifactId>
<!-- No Version or groupId -->
Malheureusement, la restructuration d'une structure d'arborescence n'est pas une option donnée à la manière dont RTC et les composants / modules ont été configurés pour ce projet. Je dois donc vivre avec la struture / la mise en page actuelle et tirer le meilleur parti de la situation. Mettre la version au niveau des parents à hériter de tous les modules d'enfants signifie essentiellement la reconstruction / retestation / redéploiement de tous les modules (pouvant être coûteux) même s'il n'y avait qu'une modification d'un seul module. Essentiellement, je perds la capacité de la version indépendante un module. Bien que je suis d'accord; Cela résoudrait mon problème de déploiement.
Si vous aimez continuer à me battre contre Maven, c'est votre tour, mais je recommande de changer la structure car elle facilitera votre vie. Mais si l'idée de déployer chaque module n'a pas de sens. Soit ils sont liés sont les ne sont pas. S'ils ne sont pas plutôt que vous devriez les rendre vraiment séparées et n'utilisez pas une construction multi-module.
J'ai du mal à comprendre comment faire cela avec le numéro de version est défini dans le parent uniquement. Dans ma configuration actuelle, je peux changer l'interface dans un module sans affecter le reste de la construction tant qu'il est temps de réintégrer la nouvelle version. Avec la version uniquement dans le parent, la modification de l'interface d'un module cassera le reste de la construction puisque tous les modules compteront sur l'arborescence source et non un binaire pré-déployé. Comment puis-je éviter ce problème? J'ai toujours besoin de version individuelle chaque module, n'est-ce pas?
Si vous avez vraiment besoin de versions séparées, ce qui signifie que dans d'autres mots, vous devez avoir des modules séparés et non une version multi-module.
Si nous résumions ce problème, il doit ressembler à ceci que je ne peux pas recommander - alors que recommandez-vous?
Vous présentez des exigences contradictoires. Vous souhaitez restructurer votre projet mais vous ne pouvez pas déplacer les choses. Vous souhaitez simplifier vos cycles de déploiement et de libération, mais vous ne voulez pas utiliser une seule version.
Étant donné que les modifications d'un module affecteront inévitablement tous les modules dépendants, j'utiliserais un schéma de version simple dans lequel tous les sous-modules héritent de la version de leur parent. Version Maven: préparer et libérer des cycles simples. Utilisez des notes de publication pour suivre vos modifications et justifier de sauter des tests inutiles des modules inchangés (les modifications apportées à une version ne modifient pas la sortie de construction / binaire du processus de construction afin que vous puissiez l'utiliser comme argument principal).
bonne chance avec votre projet.