Discussion :

[cyspeo]

Bonjour,
Je travail sur un gros projet qui utilise une hiérarchie de sous projet :
-Parent1
|-- parent-1.1
|---|
| |--sous-projet-1.1.1
| |--sous-projet-1.1.2
|--parent-1.2
...

- Projet-web
|--sous-projet
|--projet-fils (dépendance sur les projets fils du framework Parent1)

Seuls les projets fils ont du code java.

Cette gestion devient lourde et je me retrouve avec un workspace d'une dizaine de projets y compris les projets parent.
Même en créant des worksets c'est pas évident.

Je me demande si je ne devrait pas tout remettre a plat.
Puis que Projet-web utilise en dépendance uniquement des projets fils et non des projets parent, je pensait qu'il serait judicieux de travailler avec des projets sans parent.

Cela me permettrait de ne faire un checkout uniquement sur les projets que je modifie. Ça allégerait mon workspace !

Qu'en pensez vous ?

[romaintaz]

Bonjour,

Il est assez important d'avoir un projet parent car c'est lui qui disposera de toutes les informations communes, telles que les dépendances (genre à log4j, apache commons, etc.), les configurations des plugins (comme par ex. pour dire de compiler avec Java 1.6), etc.

Il y a un second concept sur les pom.xml dans Maven : l'aggregation. C'est le pom.xml qui contient la liste des modules (<modules>...</modules>). Rien ne te force à ce que le parent et les pom d'aggrégation soient les mêmes !

Donc pour faire simple, pourquoi ne pas distinguer ceux-ci, et créer un module propre au parent, comme par exemple ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
project
  +- pom.xml [pom d aggrégation des modules]
  +- parent
  |   +- pom.xml [vrai pom parent]
  +- module1
  |   +- pom.xml [pom du module1, ayant pour parent le pom parent]
  +- moduleX
  |   +- pom.xml
  +- sous-projet-1
  |   +- pom.xml [pom d aggrégation des modules du sous-projet-1]
  |   +- module-1.1
  |   |   +- pom.xml [pom du module-1.1 ayant pour parent le pom parent principal]
  |   +- module-1.X
  |       +- pom.xml
  +- sous-projet-2
  |   +- pom.xml [pom d aggrégation des modules du sous-projet-2]
  |   +- module-2.1
  |   |   +- pom.xml [pom du module-2.1 ayant pour parent le pom parent principal]
  |   +- module-2.X
  |       +- pom.xml
  ...

Dans les pom d'aggrégation, tu ne mets vraiment que le minimum : les ID + la liste des modules.
Ensuite, chaque vrai projet Java sera un enfant du parent principal.

Les avantages de cette solution:

• Tu n'as qu'un seul parent, et il est considéré comme un projet à part entière. Tu n'as pas forcément besoin de le faire évoluer en même temps que le reste, vu qu'il est censé être à peu près stable. L'idée étant d'avoir par exemple un module1 en version 1.3 qui va dépendre du parent en version 1. Si tu modifies le parent, celui-ci passera en version 2, et ainsi de suite.
• Tu n'as plus qu'un seul parent en tout, et il est commun à chaque module.
• Les pom.xml qui sont à la racine d'un ensemble de projets ne sont désormais plus que des pom d'aggrégation, et aucun module n'héritera d'eux. Du coup, il devient inutile de les avoir dans Eclipse. L'avantage de les conserver, c'est qu'en exécutant une commande Maven à la racine, Maven exécutera cette commande sur l'ensemble des modules, en faisant bien attention à l'ordre d'exécution (par rapport aux inter-dépendances). Du coup, d'un point de vue Maven, l'ensemble de tes modules ne forme au final qu'un projet unique.

Voilà, j'espère que c'est suffisament clair. Sinon, n'hésite pas à poser des questions !

[cyspeo]

J'avais pas vu l'avantage d'avoir un parent qui regroupe les informations communes.
Il n'intervient pas vraiment terme de hiérarchie. Tel que je comprend ton exemple, je le voit plus comme une spécification commune.

Avec le concept d’agrégation j'ai un peu de mal :
Quel est la différence entre un module et un sous projet ?

[romaintaz]

J'avais pas vu l'avantage d'avoir un parent qui regroupe les informations communes.
Il n'intervient pas vraiment terme de hiérarchie. Tel que je comprend ton exemple, je le voit plus comme une spécification commune.

Le but est en effet de définir toutes les choses communes dans le pom parent, comme les dépendances de base, les versions et configuration des plugins, les éventuels repositories et autres infos de projet (la liste des développeurs par exemple). Rien n'empêche de le placer où l'on veut, y compris en dehors du projet (c'est ce qui est fait sur les projets de Maven).

Avec le concept d’agrégation j'ai un peu de mal :
Quel est la différence entre un module et un sous projet ?

C'est la même chose. En réalité, un <module> défini dans un pom.xml permet à Maven de dire "hé, il y a un sous projet qui se trouve dans le répertoire XXX (XXX étant le nom du module tel que défini dans le pom), donc lance aussi mes commandes dessus !".

Ainsi, si l'on écrit :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<modules>
    <module>foo</module>
    <module>bar</module>
    <module>../toto</module>
    <module>tata/titi</module>
</modules>

Maven va comprendre qu'il y a 4 autres pom.xml à lire, structuré de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
+- mon-projet
|   +- pom.xml [Le pom d aggrégation]
|   +- foo
|   |   +- pom.xml
|   +- bar
|   |   +- pom.xml
|   +- tata
|   |   +- titi
|   |       +- pom.xml
+- toto
    +- pom.xml

[cyspeo]

C'est plus clair maintenant.
Merci beaucoup.