[Conception Plugin] Analyse de projets multi-modules

Bonjour à tous,

Je vous explique d'abord le contexte avant de vous poser plusieurs questions.

Je travaille actuellement sur un projet de développement de plugin Maven 2. Le plugin disposera en particulier d'un goal run, qui devra analyser les POM des différents modules d'un projet Maven quelconque.

Le concept de base du goal run est qu'il devra être lancé qu'une seule fois à partir du module parent (de plus haut niveau). Le plugin ne devra donc pas être éxecuté sur l'ensemble des modules fils (ce qui n'est pas le comportement par défaut de Maven).

Pur faire cela, j'ai lu la documentation de Maven, et deux options me semblent intéressantes : @aggregator et @inheritByDefault false.

Voici les questions que je me pose :

1) L'une de ce 2 options est-elle appropriée à mon problème ?
2) Je n'ai pas cerné la différence entre ces 2 options. Quelle est-elle ?


Ensuite, j'ai un autre problème.
Dans le code source de mon Mojo run, j'ai mis ceci pour récupérer le projet Maven en cours :

Code:

---

1 2 3 4 5

/**      * @parameter expression="${project}"      */ protected MavenProject project;

---

Toujours dans le contexte d'un projet multi-module et du goal run lancé une seule fois, le problème est que la variable 'project' contient le POM parent.

3) Comment accède-t-on aux POM des modules fils ? (ou comment récupérer des variables de type MavenProject correspondant au mapping des fichiers POM fils)

Voila.
Merci d'avance pour vos réponses.

Je pense avoir trouvé réponse à mes questions :

Pour récupérer les projets fils :
project.getCollectedProjects();

J'ai l'impression que Aggregator est plus adapté. Mais je veux quand même bien votre avis sur la question.

Mon avis sur les différences entre aggregator et inheritedByDefault.

aggregator
Un plugin aggregator ne sera lancé qu'une fois par réacteur, et permet d'en centraliser l'exécution et les résultats.

inheritedByDefault aura comme effet que tout module ayant un tag <parent> référençant un pom ayant ton plugin configuré aura ce même plugin configuré (pratique par exemple pour définir le maven-eclipse-plugin dans un super pom, et ne plus devoir le faire dans aucun autre pom ayant ce super pom comme ancêtre).

Pour accéder aux projets enfants, j'ai plutôt habitude d'utiliser les reactor projects, comme ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10

/**      * If the executed project is a reactor project, this will contains the full      * list of projects in the reactor.      *      * @parameter expression="${reactorProjects}"      * @required      * @readonly      */ protected List<MavenProject> reactorProjects;

---

Mais j'imagine que getCollectedProjects() doit réaliser plus ou moins la même chose.

Merci pour l'explication.
De plus, j'ai testé "reactorProjects", cela marche aussi.
Mais il y a quand même une différence avec getCollectedProjects().

En appelant getCollectedProjects(), on récupère uniquement les projets fils.
En utilisant "reactorProjects", on récupère les projets fils, mais aussi le projet actuel.

Par contre, j'ai une autre question.
Dans le livre "Maven, the definitive guide", j'ai lu :
"Aggregator is slated for deprecation in a future release of Maven".

Pourquoi ?

Si je me souviens bien, c'est parce que certains développeurs de Maven sont insatisfaits du fonctionnement actuel, et proposent de réimplémenter le tout.

OK, merci de satisfaire ma curiosité

En fait, je n'avais pas vu, mais quand on fait un goal aggregate et qu'on le lie au cycle de vie d'un projet Maven multi-module, le goal est appelé sur tous les projets fils, même si le goal est aggregate.

Comment faire pour que le goal ne soit lancé que sur le module parent, alors qu'on a lié le goal au cycle de vie du module ?

Bonjour,

avez vous trouvé une solution à votre problème à propos de la propriété inheritedByDefault ?

Aggregate, comme son nom l'indique, permet de regrouper le l'exécution de goals pour la hiérarchie de poms. L'exemple le plus courant est celui de la génération de la javadoc. Le goal est appelé depuis le parent pour tout les fils directement et ne sera pas rappelé par la suite dans le passage par les fils.

Je cherchais à faire la même chose que vous, appeler depuis un certain niveau de ma hiérarchie de poms un plugin et qu'il ne soit pas appelé dans ses sous-modules alors que je l'ai lié à une phase du cycle de vie.

InheritedByDefault à false me semble la bonne solution mais le plugin descriptor généré à l'installation de mon plugin ne prend pas en compte le tag @inheritedByDefault. Il est mit à true au lieu de false comme je l'avais défini...

C'est un autre soucis mais je souhaitais savoir si vous aviez trouvé une autre solution.

Merci d'avance.