Comment configurer correctement un projet Maven multi-modules avec des cycles de libération glissants

Question

J'essaie de trouver le meilleur moyen de configurer notre projet Apache Maven multi-modules de manière à permettre des cycles de publication de modules disparates et à éviter les problèmes de dépendance lors du débogage du projet.

Nous avons actuellement une configuration similaire à:

• bigsystem@1.2
  • SNAPSHOT parent-1.1
  • module a@1.4-SNAPSHOT
    • parenté par parent@1.1-SNAPSHOT
  • module b@1.3-SNAPSHOT
    • parenté par parent@1.1-SNAPSHOT
    • dépend de a1.1
  • module c@1.1-SNAPSHOT
    • parenté par parent@1.1-SNAPSHOT
    • dépend de a@1.2
    • dépend de b@1.1

Les dépendances déclarées dans les modules b et c contiennent la version minimale requise pour compiler le module, qui n'est pas nécessairement la version actuelle du module ou la version du module en cours de déploiement.

Du point de vue de la construction, cela fonctionne bien, chaque module peut être publié / mis à jour si nécessaire. Toutefois, lorsque vous essayez de déboguer l’application déployée sous IntelliJ IDEA (versions 8 et 9 EAP) après avoir ouvert le pom de niveau supérieur, IDEA décide que nous avons déclaré une dépendance sur a@1.2, à chaque fois que nous entrons dans l'une des classes de a, il devrait l'ouvrir à partir de a-1.2-sources.jar plutôt que des sources actuelles a@1.4 du projet. Ceci est encore plus confus par le fait que passer à l’une des classes de b nous amène à b@1.1 plutôt qu’à b@1.3.

Ma première tentative pour contourner ce problème a été de déclarer les numéros de version dans la section dependencyManagement du pom parent et de laisser les sous-modules hériter de la version. Cela a permis de résoudre le problème de débogage d'IDEA, car la section dependencyManagement peut indiquer à tout le monde les versions actuelles de -SNAPSHOT.

Cela pose malheureusement un problème lors de la publication de maven, car il doit libérer le pom parent avant de publier le module. Toutefois, comme le parent peut faire référence à plusieurs scripts en cours de développement, il ne peut pas être publié et nous ajoutons références de version aux modules pom pour satisfaire la version.

Il semblerait que l’utilisation de la section dependencyManagement de maven ne fonctionnerait vraiment bien que si nous publiions TOUTES les offres en même temps, qu’elles aient été modifiées ou non, mais nous souhaitons gérer les versions de chaque sous-module uniquement lorsque cela est nécessaire. le modèle ne semble pas correspondre.

Je soupçonne qu'il me manque quelque chose et qu'une combinaison de dependencyManagement et de plages de versions peut satisfaire aux exigences, même si je n'ai pas encore vu les plages de versions fonctionner correctement.

Y a-t-il un meilleur moyen? Une bonne manière?

Answer 1

La solution finale / de travail que nous avons finalement utilisée était assez similaire à celle avec laquelle nous avons commencé. La structure actuelle du projet reste la même:

• bigsystem@1.2
  • SNAPSHOT parent-1.1
  • module a@1.4-SNAPSHOT   o parenté par parent@1.1-SNAPSHOT
  • module b@1.3-SNAPSHOT   o parenté par parent@1.1-SNAPSHOT   o dépend de a1.1
  • module c@1.1-SNAPSHOT   o parenté par parent@1.1-SNAPSHOT   o dépend de a1.2   o dépend de b@1.1
  • distribution a@1.2-SNAPSHOP

Cependant, les principales différences sont les suivantes:

• le module parent n'inclut aucune version des artefacts de projet
• les modules individuels déclarent entièrement leurs dépendances de projet et spécifient une plage de versions, c'est-à-dire [1.0.0,1.1.0)
• tous les modules commencent leurs cycles de numéro de version à partir de .1, c'est-à-dire 1.0.1-SNAPSHOT, ce qui permet à la plage de versions d'être satisfaite par les instantanés initiaux (1.0.0-SNAPSHOT est antérieure à 1.0.0 final, elle n'est donc pas incluse).
• distribution pom (non indiqué initialement dans la question) identifie la version exacte à déployer / à inclure dans une version spécifique.
• supprimez tous les projets -SNAPSHOTS du référentiel maven local lors de la libération afin que les collectes de ramassage de plages uniquement (ou utilisez -Dmaven.repo.local = / tmp / sometemprepo pour un nouveau référentiel local)

Cela rend chaque module plus autonome et nous donne la liberté de publier et de déployer de nouvelles versions de nos artefacts de projet avec un minimum de complications.

Answer 2

Je recommanderais de ne pas en faire des modules, mais de rendre leurs POM indépendants. De cette façon, vous n'avez pas à vous soucier d'essayer de satisfaire les dépendances POM parentes. Puisqu'ils sont publiés indépendamment, ils devraient vraiment avoir des modèles d'objet de projet indépendants. Pensez à Apache Commons comme modèle.

Answer 3

Je pense que le problème avec IDEA se pose parce que vous utilisez le POM racine dans votre structure source pour effectuer deux opérations qui s'excluent généralement mutuellement dans Maven. Vous utilisez d’abord le POM en tant qu’emplacement pour stocker les informations de configuration communes des projets Maven non liés (d’un point de vue de la construction). Deuxièmement, vous utilisez le POM en tant qu’agrégateur pour votre construction. Vous pouvez faire chacune de ces choses sans faire l'autre.

Comme Rob l'a dit, supprimez vos projets de module a, b, etc. de la section modules de votre POM parent. Deuxièmement, déplacez votre POM parent vers son propre répertoire car il s’agit d’un frère des autres modules en ce qui concerne votre processus de construction et de publication. Comme vous l'avez maintenant, c'est plus un parent / agrégateur.

La façon dont vous l'avez maintenant ne permet pas de marquer ni de publier chaque module individuellement, car une balise de votre POM parent inclurait probablement inutilement tous les sous-dossiers du module.

Votre structure de fichier ressemblerait à:

• parent
  • pom.xml
• module a
  • pom.xml
• module X
  • pom.xml

En ce qui concerne ce qui vous manque, dependencyManagement n’est pas vraiment adapté à la gestion des versions pour les dépendances intra-projet. C’est la dépendance entre les modules d’une génération agrégée Il convient mieux à la déclaration de versions globales pour les dépendances externes.

Answer 4

Ils semblent certainement être des modules séparés. Quels avantages en retirez-vous si elles ont des dépendances différentes, même dans le cadre d’un projet multi-modules?