Discussion :

[polymorphisme]

Bonjour,

débutant avec Maven, je bute avec un problème de fichier pom parent.

J'ai créer mon fichier parent pom dans le répertoire tutorial05 :

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
<project xmlns="http://maven.apache.org/POM/4.0.0" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 
  <modelVersion>4.0.0</modelVersion>
  <packaging>pom</packaging>
 
  <groupId>com.p</groupId>
  <artifactId>tutorial05</artifactId>
  <version>1.0.0</version>
 
  <name>Cocoon Getting Stared application [parent]</name>
 
  <modules>
    <module>myCocoonWebapp</module>
    <module>myBlock1</module>
    <module>myBlock2</module>
  </modules>
</project>

Et, j'ai inséré l'élément parent dans chacun des fichiers pom des modules
myCocoonWebapp, myBlock1, et myBlock2 :

Code :

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

1
2
3
4
5
 <parent>
    <groupId>com.p</groupId>
    <artifactId>tutorial05</artifactId>
    <version>1.0.0</version>
 </parent>

La commande mvn jetty:run me retourne l'erreur :

Reason: Cannot find parent: com.p:tutorial05 for project: com.p:myCocoonWebApp:war:1.0.0 for project com.p:myCocoonWebApp:war:1.0.0

Merci de votre aide.

[nannous]

Bonjour,
Quelle est la structure des tes projets ?
Quels sont les emplacements de ton pom parent et de tes modules <module>myCocoonWebapp</module>
<module>myBlock1</module>
<module>myBlock2</module> ?

[polymorphisme]

Bonjour nannous,

voici l'arborescence de mon répertoire de travail getting-started-app:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
pom.xml 
tutorial05
 +-myBlock1
 |  +-pom.xml
 |  +-src
 |     +-[...]
 +-myBlock2
 |  +-pom.xml
 |  +-src
 |     +-[...]
 +-myCocoonWebapp    
    +-pom.xml
    +-src
       +-[...]

En espérant que cela t'aide, merci

[romaintaz]

Fais un mvn install avant, de façon à installer le pom parent dans le repository local.

[nannous]

Ou sinon mets le pom parent dans le dossier tutorial 5

[thebloodyman]

Fais un mvn install avant, de façon à installer le pom parent dans le repository local.

Cela ne changera rien puisque le problème n'est pas un problème de dépendance introuvable mais de structure non valide.

Ou sinon mets le pom parent dans le dossier tutorial 5

Oui, c'est la convention puisque par défaut, le module s'attend à trouver le pom.xml parent au niveau de son dossier parent : soit tutorial05.

[romaintaz]

Je ne suis pas tellement sûr de ce que tu indiques. Maven, lorsqu'il rencontre la balise parent va tenter de gérer ce projet parent comme n'importe quelle dépendance (hormis si l'on précise le relativePath dans le noeud parent), et donc sera recherché au sein du repository local (et à défaut des repositories d'entreprises).

Cependant, ici ce n'est pas la compilation qui pose problème, mais l'exécution d'un plugin (jetty). Peut-être que ce plugin cherche effectivement le pom.xml parent au sein du répertoire parent.

Autre chose : la notion de parent et celle de modules sont deux choses distinctes dans Maven, même s'ils sont très souvent utilisées ensemble. Ainsi, un pom.xml parent peut tout à fait ne disposer d'aucun module (cas fréquent, il suffit de voir les nombreux org.apache.maven.maven-parent par exemple), tout comme un module peut ne pas avoir de parent (ce cas là est cependant assez rare je pense).

Cela dit, je suis tout à fait d'accord qu'il est préférable de disposer le pom.xml parent au sein du répertoire parent des modules.

Mais quand je vois le pom.xml parent de polymorphisme, on y voit la déclaration suivante des modules :

Code :

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

1
2
3
4
5
  <modules>
    <module>myCocoonWebapp</module>
    <module>myBlock1</module>
    <module>myBlock2</module>
  </modules>

et non :

Code :

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

1
2
3
4
5
  <modules>
    <module>tutorial05/myCocoonWebapp</module>
    <module>tutorial05/myBlock1</module>
    <module>tutorial05/myBlock2</module>
  </modules>

ce qui me laisse penser que le pom.xml est bien situé dans le répertoire tutorial05...
Ainsi la commande mvn install pourrait résoudre le problème.

[thebloodyman]

Salut,

Oui, autant pour moi, techniquement cela résoudrait le problème.
Mais ce que je voulais dire que c'est davantage une solution de contournement et apparemment on est d'accord la dessus.

Cela dit, je suis tout à fait d'accord qu'il est préférable de disposer le pom.xml parent au sein du répertoire parent des modules.

Un projet parent peut en effet être résolu comme une dépendance.
Maintenant, à partir du moment ou le projet parent n'est pas une dépendance tiers (qui définit par exemple des éléments partagés par plusieurs autre projets maven) mais une dépendance forte du projet qui définit des sous modules, faire un install du projet parent est bien moins logique que de permettre les modules de voir leur parent lors de la phase de résolution des dépendances.
En tous les cas, la structure du projet de ce post est l'exemple typique de dépendance forte entre un parent et ses modules enfant.

Le défaut de la solution "install du parent" dans ce cas est assez simple :
tu vas au niveau parent, tu fais un install pour permettre aux modules de résoudre leur dépendance parente. Maintenant, si le parent n'est que le parent de ces modules (comme dans l'exemple), à quoi bon se fatiguer à faire des install du parent manuellement ?
En outre, chaque modification du pom.xml parent doit faire l'objet d'une installation sur le repo local pour que le module enfant soit à jour alors que dans dans ce contexte le parent n'existe que pour ses 3 sous modules.
C'est la porte ouverte aux bugs et oublis en tout genre.

Maintenant, si le projet parent ne définissait pas des modules précis mais des éléments générales pour plusieurs autres projets Maven : properties, distribution management, repos etc... ca serait une autre histoire. Et dans ce cas la, je trouverais logique d'installer la dépendance manuellement puisqu'elle est a une corrélé plus faible avec les autres projets maven qui dépendent d'elle.

[romaintaz]

Je ne trouve pas le fait de faire l'installation du parent si absurde. Certes on peut facilement indiquer à tel ou tel module où se trouve le pom.xml parent (grâce au relativePath). Dans un cas comme ici, utiliser cette information n'est pas, je pense, une mauvaise pratique.

Mais d'une façon générale, ce n'est pas une mauvaise idée de faire un mvn install en règle générale. Prennons un projet structuré ainsi :

Code :

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

1
2
3
4
5
6
monProjet
  + pom.xml
  + core
  |    + pom.xml
  + appli
        + pom.xml

où appli a une dépendance sur core. Si tu ne fais pas un install de core avant de compiler appli, cette dernière compilation échouera, ou pire encore, elle prendra une version compilée de core qui date de la dernière installation (cas où la version de core ne change pas, comme par ex. avec une dépendance SNAPSHOT) et qui n'est pas a priori pas la dernière version du code...

Donc installer les dépendances dans le repo local, y compris les parents, ne me parait pas si saugrenue comme idée

[thebloodyman]

Je pense que c'est une question de préférence et aussi du nombre de module à installer.

Dans ton exemple, certes, le core devrait être à jour lorsque tu compiles appli.
Maintenant pour cela, il suffit de travailler au niveau parent et non des modules.
En faisant un compile/install depuis le parent, chaque module sera compiler/installer selon l'ordre défini par la parent.
Ainsi, le core sera à jour pour appli.
Sur un petit projet ou la compilation/installation depuis le projet est rapide, je trouve saugrenue (taquinade ) d'installer le core manuellement. C'est plus simple de compiler et d'installer directement depuis le parent.

Maintenant il y a des exceptions.
Lorsque j'ai un projet parent avec une nuée de modules qui prennent trop de temps à compiler (+ 30 sec ), je fais parfois le choix d'installer uniquement certains modules(ce qui ont changé) pour gagner du temps. Mais après c'est une question de rigueur : ne pas oublier d'installer chaque module impacté.

En tout cas, intéressant sujet, merci pour la discussion

[romaintaz]

C'est effectivement vrai. De mon côté, je ne compile pas avec Maven durant mes dévs, je laisse Eclipse s'en charger (utilisation du mvn eclipse:eclipse et non de m2eclipse).
Toutefois, quand je souhaite réaliser une vraie release je me fais un simple mvn clean install, au niveau parent bien entendu.
Concernant l'I.C., là aussi, je ne me prends pas la tête : mvn clean install.
Dans le cas où le build est long, alors on peut réaliser un certain nombre de tâches différentes pour résoudre le problème :

• séparer les tests afin que ceux qui prennent du temps soient exécutés moins souvent (nightly builds par ex.)
• Séparer les modules en plusieurs jobs Hudson
• Utiliser maven 3 et tenter le coup du build parallélisé ou du shell maven
• Refactoriser pour que la compilation / les tests soient plus rapides
• Changer le matériel
• Changer les développeurs

[thebloodyman]

Je suis plutot plugin eclipse M2

Pour le build long, tes propositions sont intéressantes pour l'IC.
Maintenant pour le développement,c'est pas toujours évident.
J'ai constaté le problème sur un vieux projet dont les tests prenaient 10 bonnes minutes.
Pas mal de developpeurs commités souvent sans lancer les tests (pour pas perdre 10 mn), résultat : on récupérait parfois des versions qui cassaient le build.

L'option

Refactoriser pour que la compilation / les tests soient plus rapides

était prometteuse mais il y avait un tel coût que cela ne sait jamais fait.

Sinon, l'option Maven3 avec Build parallélisé, ca semble assez sympa.
Après faudrait faire une comparaison avec et sans.
J'ai pas encore testé Maven3. J'attends que les plus courageux se cassent d'abord les dents dessus pour remonter les bugs bloquants

[romaintaz]

Pas mal de developpeurs commités souvent sans lancés les tests (pour pas perdre 10 mn), résultat : on récupéraient parfois des versions qui cassaient le build.

Cas assez connu effectivement. L'une des parades est le commit pré-testé. C'est à dire que le developpeur commite sa modif, puis l'outil d'I.C. (en l'occurence TeamCity) builde et lance les tests sur le projet en intégrant cette nouvelle modification. Si tout se passe bien, le commit est effectivement accepté pour être placé dans le gestionnaire de sources. Si une erreur est rencontrée, le vilain développeur est averti et son commit refusé. L'intérêt d'un tel système est que le gestionnaire est (censé être) toujours clean. Cool quoi.

Voir ce merveilleux article pour plus d'infos
L'un de mes anciens collègue, David Gageot a également écrit sur son blog un article traitant de l'I.C. sans serveur (en utilisant Git et un script). Très intéressant à lire, mais là on s'éloigne (encore plus ) du sujet...

Sinon, l'option Maven3 avec Build parallélisé, ca semble assez sympa.
Après faudrait faire une comparaison avec et sans.
J'ai pas encore testé Maven3. J'attends que les plus courageux se cassent d'abord les dents dessus pour remonter les bugs bloquants

J'ai pas mal de retours sur Maven 3. Niveau compatibilités, à quelques rares exceptions sur des plugins, ça se passe très bien. Quant au gain de performances, il n'est pas encore super évident. Mais j'attends avec hâte qu'un outil d'I.C. intègre le shell Maven !!

Au fait, tu utilises bien m2eclipse, mais tu as changé le Maven par défaut ? Parce que les dernières version de ce plugin intégre nativement maven3. Alors peut être l'utilises tu sans le savoir

[thebloodyman]

L'une des parades est le commit pré-testé. C'est à dire que le developpeur commite sa modif, puis l'outil d'I.C. (en l'occurence TeamCity) builde et lance les tests sur le projet en intégrant cette nouvelle modification. Si tout se passe bien, le commit est effectivement accepté pour être placé dans le gestionnaire de sources. Si une erreur est rencontrée, le vilain développeur est averti et son commit refusé. L'intérêt d'un tel système est que le gestionnaire est (censé être) toujours clean. Cool quoi.

L'idée est louable. L'inconvénient est que le temps pour que le commit (propre) soit effectif sur le svn des développeurs est plus long puisque l'ic valide avant.
Parfois, ce n'est pas génant. Maintenant, quand il faut corriger quelque chose assez rapidement pour débloquer les autres développeurs ou qu'un de tes collègues est pressé que tu commit pour pouvoir avancer, c'est pas toujours simple.
La solution passe surement par un processus de validation depuis l'IC assez rapide.
Merci pour les liens, je lirais ça à mes heures perdues

J'ai pas mal de retours sur Maven 3. Niveau compatibilités, à quelques rares exceptions sur des plugins, ça se passe très bien. Quant au gain de performances, il n'est pas encore super évident. Mais j'attends avec hâte qu'un outil d'I.C. intègre le shell Maven !!

Bonne nouvelle !
Le shell maven ca a l'air bien sympa ca aussi

Au fait, tu utilises bien m2eclipse, mais tu as changé le Maven par défaut ? Parce que les dernières version de ce plugin intégre nativement maven3. Alors peut être l'utilises tu sans le savoir

Oui, je n'utilise pas le maven embeded fournit avec le plugin mais le maven installé sur ma machine.
C'est en effet une version béta de Maven 3
Ca m'a fait halluciner quand j'ai vu ça la première fois : allez zou, manger vous une béta