Maven parent vs modules pompon

Question

Il semble y avoir plusieurs façons de structurer le parent de chrysanthèmes dans un multiprojet construire et je me demandais si quelqu'un avait une idée sur ce qui sont les avantages / inconvénients de chaque moyen.

La méthode la plus simple de demander à un parent de pom serait de le mettre dans la racine d'un projet c'est à dire

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

où l'pom.xml est à la fois le projet parent ainsi que le décrit le cœur de l'api et de l'application des modules

La méthode suivante consiste à séparer la mère de son propre sous-répertoire comme dans

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

Lorsque le parent pom contient toujours les modules, mais ils sont par rapport, par exemple ../myproject-core

Enfin, il y a l'option dans laquelle le module de la définition et de la mère sont séparés comme dans

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

Lorsque le parent pom contient tout "partagé" de la configuration (dependencyManagement, propriétés, etc.) et la myproject/pom.xml contient la liste des modules.

L'intention est d'être adaptable à une grande échelle, ce qui devrait être adaptable à un grand nombre de projets et d'artefacts.

Quelques bonus de questions:

• Où est le meilleur endroit pour définir les différentes configuration partagée que dans le contrôle de code source, le déploiement des répertoires, commune de plugins etc. (Je suis en supposant que le parent, mais j'ai souvent été mordu par cela et ils se sont retrouvés dans chaque projet, plutôt que d'une commune).
• Comment faire le maven-release-plugin, hudson et nexus traitent de la manière dont vous configurez votre multi-projets (peut-être un géant de la question, c'est plus si quelqu'un a été surpris quand, par la façon dont un multi-projet de construction a été mis en place)?

Edit: Chacun des sous-projets ont leur propre pom.xml j'ai oublié de le garder laconique.

Answer 1

À mon avis, pour répondre à cette question, vous devez penser en termes de cycle de vie du projet et le contrôle de version. En d'autres termes, le parent pom avoir son propre cycle de vie, c'est à dire peut-il être publié séparément des autres modules ou pas?

Si la réponse est oui (et c'est le cas de la plupart des projets qui ont été mentionnés dans la question ou dans les commentaires), puis le pom parent a besoin de son propre module à partir d'un CV et d'une Maven point de vue et vous vous retrouvez avec quelque chose comme ceci à la VCS niveau:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

Cela rend la caisse un peu douloureux et un bon moyen d'en sortir est d'utiliser svn:externals. Par exemple, ajouter un trunks annuaire:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

Avec la suite externes définition:

parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk

Une caisse d' trunks serait alors le résultat suivant structure locale (modèle #2):

root/
  parent-pom/
    pom.xml
  projectA/

En option, vous pouvez même ajouter un pom.xml dans la trunks annuaire:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

Cette pom.xml est une sorte de "faux" pom: il n'est jamais sorti, il ne contient pas une version réelle étant donné que ce fichier n'est jamais sorti, il ne contient qu'une liste de modules. Avec ce fichier, une caisse serait à l'origine de cette structure (schéma n ° 3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

Ce "hack" permet de lancer un réacteur de construire à partir de la racine après une extraction et de rendre les choses encore plus pratique. En fait, c'est combien de j'aime pour l'installation de projets maven et un dépôt VCS pour de grandes construit: il fonctionne, tout simplement, qu'il évolue bien, il donne toute la souplesse dont vous avez besoin.

Si la réponse est non (retour à la question initiale), alors je pense que vous pouvez vivre avec le motif n ° 1 (la chose la plus simple qui pourrait éventuellement fonctionner).

Maintenant, à propos de la prime de questions:

• Où est le meilleur endroit pour définir les différentes configuration partagée que dans le contrôle de code source, le déploiement des répertoires, commune de plugins etc. (Je suis en supposant que le parent, mais j'ai souvent été mordu par cela et ils se sont retrouvés dans chaque projet, plutôt que d'une commune).

Honnêtement, je ne sais pas comment faire pour ne pas donner une réponse générale (comme "utiliser le niveau à partir duquel vous pense qu'il est judicieux de mutualiser les choses"). Et de toute façon, l'enfant poms pouvez toujours remplacer les paramètres hérités.

• Comment faire le maven-release-plugin, hudson et nexus traitent de la manière dont vous configurez votre multi-projets (peut-être un géant de la question, c'est plus si quelqu'un a été surpris quand, par la façon dont un multi-projet de construction a été mis en place)?

L'installation que j'ai utiliser fonctionne bien, rien de particulier à mentionner.

En fait, je me demande comment le maven-release-plugin traite le motif n ° 1 (en particulier avec l' <parent> section puisque vous ne pouvez pas avoir INSTANTANÉ de dépendances lors d'une sortie). Cela sonne comme un poulet ou des oeufs de problème mais je ne m'en souviens pas si il fonctionne et a été trop paresseux pour faire le test.

Answer 2

De par mon expérience, Maven meilleures pratiques, il y a deux sortes de "parent poms"

• "société" parent pom - ce pom contient votre spécifiques à la société de l'information et de la configuration qui héritent tous de pom et n'a pas besoin d'être copié. Ces informations sont:

  • les référentiels
  • distribution gestion des articles
  • commune de configurations de plugins (comme maven-compiler-plugin versions source et cible)
  • de l'organisation, des développeurs, etc

  La préparation de ce parent pom doivent être faites avec prudence, car toute votre entreprise pdm va hériter d'elle, de sorte que cette pom être mature et stable (libérant une version de pom parent ne devrait pas affecter à la libération de tous vos projets de l'entreprise!)

• deuxième type de parent pom est un multimodule parent. Je préfère ta première solution - c'est un défaut de maven convention pour le multi projets de module, très souvent représente VCS structure du code

L'intention est d'être adaptable à une grande échelle, ce qui devrait être adaptable à un grand nombre de projets et d'artefacts.

Mutliprojects de structure de l'arbre - de sorte que vous ne sont pas arrown à un niveau de pom parent. Essayez de trouver un projet struture pour vos besoins - un classique exmample est de savoir comment disrtibute mutimodule projets

distibution/
documentation/
myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml
pom.xml

Quelques bonus de questions:

• Où est le meilleur endroit pour définir les différentes configuration partagée que dans le contrôle de code source, le déploiement des répertoires, commune de plugins etc. (Je suis en supposant que le parent, mais j'ai souvent été mordu par cela et ils se sont retrouvés dans chaque projet, plutôt que d'une commune).

Cette configuration doit être judicieusement découpé en une "société" parent pom et projet pom parent(s). Les choses liées à l'ensemble de votre projet, allez à la "société" mère et il s'agit de l'actuel projet d'aller à un projet.

• Comment faire le maven-release-plugin, hudson et nexus traitent de la manière dont vous configurez votre multi-projets (peut-être un géant de la question, c'est plus si quelqu'un a été surpris quand, par la façon dont un multi-projet de construction a été mis en place)?

Société mère pom être libéré en premier. Pour multiprojects règles standard s'applique. Serveur CI ont besoin de tout savoir pour construire le projet correctement.

Answer 3

1. Un des parents est la meilleure pratique pour le partage de la configuration et des options à travers autrement découplée des composants. Apache a un parent pom projet afin de partager des avis juridiques et des options d'emballage.

2. Si votre projet de niveau supérieur a un réel travail, comme dans le cas de l'agrégation javadoc ou de l'emballage d'une libération, alors vous aurez des conflits entre les paramètres nécessaires pour faire ce travail et les paramètres que vous souhaitez partager par le parent. Un parent uniquement à éviter que.

3. Un modèle commun (en ignorant #1 pour l'instant) ont des projets-avec-code d'un projet parent en tant que parent, et d'utiliser le haut-niveau en tant que parent. Cela permet de cœur des choses à être partagées par tous, mais permet d'éviter le problème décrit dans la #2.

4. Le site plugin va faire très confus si la structure mère n'est pas la même que la structure de répertoire. Si vous voulez construire un site global, vous aurez besoin de faire quelques tripoter de contourner ce problème.

5. Apache CXF est un exemple du schéma en #2.

Answer 4

Il y a un petit piège avec la troisième approche. Depuis agrégation des Pdm (myproject/pom.xml) n'ont généralement pas de parents du tout, ils ne partagent pas la configuration. Cela signifie que tous ceux d'agrégation POMs aura seulement les répertoires par défaut.

Ce n'est pas un problème si vous utilisez uniquement les plugins de Centrale, cependant, ceci ne fonctionnera pas si vous exécutez un plugin à l'aide du plugin:objectif format de votre référentiel interne. Par exemple, vous pouvez avoir foo-maven-plugin avec l'id de groupe de org.example fournissant de l'objectif generate-foo. Si vous essayez d'exécuter à partir de la racine du projet à l'aide de la commande comme mvn org.example:foo-maven-plugin:generate-foo, il ne pourra pas s'exécuter sur l'ensemble des modules (voir la note sur la compatibilité).

Plusieurs solutions sont possibles:

1. Déployer plugin pour le Maven Central (pas toujours possible).
2. Spécifier référentiel de l'article dans l'ensemble de votre regroupement de Chrysanthèmes (pauses SÈCHE principe).
3. Ont ce référentiel interne configuré dans le settings.xml (que ce soit en local settings dans ~/.m2/settings.xml ou dans les paramètres globaux /conf/settings.xml). Va faire construire échouer sans ces settings.xml (peut-être OK pour les grands projets qui ne sont jamais censés être construit à l'extérieur de l'entreprise).
4. Utilisez le parent avec les référentiels de paramètres dans votre regroupement des Pdm (peut-être trop de parent Pdm?).