Discussion :

[Croc]

Bonjour à tous,

Étant donné que je sèche depuis de début de la soirée là dessus... Je craque et de demande un peu d'aide. Le contexte du problème est le suivant : Je déploie maven sur un projet de 17 {sous*}-modules articulés de la façon suivante :

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
 
-- super-pom
---- projet 1 (package type pom)
-------- sous-projet 1.1 (package type jar)
-------- sous-projet 1.2 (package type jar)
-------- sous-projet 1.3 (package type jar)
---- projet 2 (package type pom)
-------- sous-projet 2.1 (package type jar)
-------- sous-projet 2.2 (package type jar)
---- projet 3 (package type pom)
-------- sous-projet 3.1 (package type jar)
-------- sous-projet 3.2 (package type jar)
-------- sous-projet 3.3 (package type jar)
-------- sous-projet 3.4 (package type jar)
...

Il y a pas mal de dépendances un peu partout.
La plus intéressante est que le sous-projet 2.2 déclare une dépendance vers le projet 1 (qui est de type pom):

Code :

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

1
2
3
4
5
6
7
 
<dependency>
     <groupId>com.company.project</groupId>
     <artifactId>projet1</artifactId>
     <type>pom</type>
     <version>1.2.0-SNAPSHOT</version>
</dependency>

En compilation, test, installation et déploiement, tout passe impeccable. Les pom et les jar sont correctement créés dans le repository local, tout est normal.

Lorsque je lance un :

Code :

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

mvn release:prepare -DdryRun:true

Tout est OK aussi... Pas d'erreur.

Etant donné que je travaille avec des snapshots, j'ai cru bon d'utiliser l'argument -DallowTimestampedSnapshots lors de l'invocation du plugin release :

Code :

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

mvn clean release:prepare -DallowTimestampedSnapshots

Le plugin me demande d'acquitter toutes les versions (release + next) et lance un [clean, verify] sur tout le projet (sans doute avant de commiter).
Toute les dépendances sont correctement traitées, sauf celle du projet 2.2.

Le message d'erreur étant le suivant :

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
 
  [INFO] [clean:clean]
  Downloading: http://repo1.maven.org/maven2/com/company/project/projet1/1.2.0/projet1-1.2.0.pom
  Downloading: http://repo1.maven.org/maven2/com/company/project/projet1/1.2.0/projet1-1.2.0.pom
  [INFO] ------------------------------------------------------------------------
  [ERROR] BUILD ERROR
  [INFO] ------------------------------------------------------------------------
  [INFO] Failed to resolve artifact.
 
  Missing:
  ----------
        1) com.company.project.projet1:pom:1.2.0
          Path to dependency: 
          	1) com.company.project.sous-projet2.2:sous-projet2.2:jar:1.1.0
          	2) com.company.project.projet1:pom:1.2.0

Pourquoi ce comportement pour les dépendances de type pom ?

J'ai bien sûr vérifié que le problème venait bien de là. En effet, au lieu de délcarer la dépendance sur le projet1, j'ai testé en déclarant à la place une dépendance sur les sous-projets du projet 1 (tous de type jar) et là... çà passe...

Quelqu'un a-t-il une idée ?

Merci beaucoup à tous ceux qui pourront m'apporter une réponse, un début de réponse ou une nouvelle piste où chercher.

Merci beaucoup.

Jean-Baptiste.

PS : Je n'ai rien vu dans la base de bug Jira qui ressemble à çà... J'en déduit donc que je dois mal m'y prendre...

[tchize_]

Faudrait que t'explique l'intérêt pour toi de la dépendance de type pom. Si je suis la logique de maven, c'est censé ramener project1.pom dans le classpath de compilation. Pas très utile....

[Croc]

Bonjour,

L'intérêt de ces projets pom est de "centraliser" la gestion des dépendances. En effet, au lieu de déclarer les 6 ou 7 dépendances dans chacun des projets qui en a besoin, je déclare un projet pom avec les 6 ou 7 dépendances (une sorte de table des matières), et tous les projets jar (ou pom) qui ont besoin de ces dépendances déclarent comme seule et unique dépendances le pom table des matières.

Je ne sais pas si je suis clair... Est-ce là mon erreur ?

Merci en tout cas pour ce début de réponse.

Bonne journée.
Jean-Baptiste

[tchize_]

Si tu veux fonctionner comme çà, tu dois travailler par héritage, en utilisant un pom parent. Je ne suis pas certains qu'on puisse si facilement utiliser <type>pom</type>. Je ne sais déjà pas comment se comporterais maven si je rajoutais une dépendence à un war, alors une dépendance à un pom

Extrait du xsd à propos de <type> dans dependency.

This defaults to jar. While it usually represents the extension on the filename of the dependency, that is not always the case. A type can be mapped to a different extension and a classifier. The type often correspongs to the packaging used, though this is also not always the case. Some examples are jar, war, ejb-client and test-jar.
New types can be defined by plugins that set extensions to true, so this is not a complete list.

De plus, imaginons que project2 aie besoin de X, Y et Z en version 2, mais qu'il utilise, comme ton cas, une dépendance à project1 pour ajouter X,Y,Z ("table des matières" en gros. Le problème, c'est que tes dépendances sont 1 niveaux plus bas (elles deviennent des dépendances indirecte) et çà change leur priorité de version dans la résolution de conflit, donc même si çà marchait, çà resterait une mauvaise idée. Les libraries que tu utilise directement, tu dois les déclarer explicitement (best practice) pour garder la cohérence dans la gestion des versions. Exemple

project B dépend de project A qui lui même utilise struts.
project B utilise aussi explicitement struts (exemple, il crée des ActionForm)
alors, on met aussi struts dans les dépendances de project B, comme çà on sait que, même si plus tard on désolidarise B de A, B gardera ses dépendances à struts. De même, quand C dépendra de B, les dépendance à struts ne seront quà 1 niveau plus bas, au lieux de deux si t'avais C -> B -> A -> struts.