Sous super-pom ?

Bonjour,

j'essaye de définir des paramêtres qui doivent être dans le fichier pom.xml (developers, distributionManagement, ...) dans un pom générique.

Ce fichier peut-il aller dans le dossier .m2 ? à côté de settings.xml ?

Si non, où puis-je placer ce fichier pour éviter de devoir définir ces valeurs pour chaque projet ?

Merci d'avance.

C'est un projet à part entière. Tu lui définis un packaging de type pom, un groupId, un artifactId et une version. Par ex:

Code:

---

1 2 3 4 5 6 7 8 9

<project> <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>companyparent</artifactId> <version>1</version> <packaging>pom</packaging>   ... // Toutes tes propriétés </project>

---

Tu l'installes (mvn install) dans ton repository, puis dans tes projets enfants, tu lui fais référence dans le noeud parent :

Code:

---

1 2 3 4 5 6 7 8 9

<project> <modelVersion>4.0.0</modelVersion> <parent> <groupId>caf.opm.calculator</groupId> <artifactId>parent</artifactId> <version>2</version> </parent> <artifactId>mon-projet</artifactId> ...

---

le pom parent peut être n'importe où ? ou es-ce qu'il doit obligatoirement être un dossier au dessus ?

le pom parent est récupéré de la même manière que les dépendances. via les repositories. Maintenant dans le tag parent on peux définier location pour préciser dans quel dossier le trouver si il est pas dans les repos.

Terrible ! c'est génial, j'aime maven de plus en plus :D

Par contre j'ai une question :

j'aimerais connaître l'arborescence type (ou la plus facile à utiliser) pour 2 projets P1 et P2, qui utiliseraient une même librairie L ?

Citation:

---

....../projets
....../-> pom.xml
....../-> P1
....../------> pom.xml
....../-> P2
....../------> pom.xml
....../-> L
....../------> pom.xml

---

a priori, si P1 et P2 n'ont rien à voir:

Code:

---

1 2 3 4 5 6 7 8 9 10

projects company-root pom.xml (info sur la société et ses repository internes) P1 pom.xml (avec dépencande vers L en version x.y.z) P2 pom.xml (avec dépencande vers L en version a.b.c) L pom.xml

---

C'est un peu vague comme contexte.

Maven propose un concept d'aggrégation. En gros, ça te permet de diviser ton projet en plusieurs modules, généralement liés. Exemple : j'ai une application web, et je désire la diviser en trois : la partie commons, la partie services et la partie web.
Dans cet exemple, je vais établir une structure de ce genre :

Code:

---

1 2 3 4 5 6 7 8

project +- pom.xml +- commons | +- pom.xml +- services | +- pom.xml +- web +- pom.xml

---

Dans le pom.xml de services, je vais définir une dépendance vers commons.
Concernant le pom.xml à la racine, il s'agira d'un pom d'aggrégation. Il va définir en son sein la liste des modules :

Code:

---

1 2 3 4 5

<modules> <module>commons</module> <module>services</module> <module>web</module> </modules>

---

(le "nom" de ces modules est en fait le nom du répertoire le contenant)

L'intérêt de l'aggrégation, c'est que Maven va exécuter toute commande lancée au niveau de la racine sur chaque module. Bien entendu, Maven va faire ça intelligemment (grâce au Reactor), c'est-à-dire qu'il va déterminer l'ordre d'exécution. Dans mon exemple, Maven va compiler dans l'ordre commons, puis services (car services a une dépendance sur commons).

Dans mon exemple, si je lance la commande mvn clean install à la racine, ça revient à faire :

Code:

---

1 2 3 4 5 6 7

cd commons mvn clean install cd ..\services mvn clean install cd ..\web mvn clean install cd ..

---

A noter qu'un pom d'aggrégation et un pom parent sont deux concepts différents mais pas forcément exclusifs. Le pom.xml à la racine peut ainsi être le pom.xml d'aggrégation et le pom parent de tous les sous-modules.

Pour en revenir à ta question, la structure sur le disque (et donc sur ton CVS/SVN/...) va dépendre du lien entre les projets. Par exemple, si la librairie L est utilisée par projet1 et projet2 mais qu'elle n'a pas forcément de lien avec ces projets (par ex. si L est une librairie d'utilitaires), alors il n'y a pas de raison qu'elle se trouve dans le même répertoire que ces autres projets.
De toutes façons, pour Maven, ça n'a pas plus d'importance que ça, vu qu'il va toujours passer par le repository local (ou distant) pour chercher une dépendance...

Bon, j'espère t'avoir apporté les éléments permettant de répondre à ta question.

Merci beaucoup a vous 2, c'est génial.