web-dev-qa-db-fra.com

Maven ne reconnaît pas les modules frères lors de l'exécution de la dépendance mvn: arborescence

J'essaie de mettre en place un projet Maven multi-modules, et les dépendances inter-modules ne sont apparemment pas configurées correctement.

J'ai:

<modules>
  <module>commons</module>
  <module>storage</module>
</modules>

dans le POM parent (qui a un pom de type emballage), puis dans les sous-répertoires commons/ et storage/ qui définissent les poms JAR du même nom.

Le stockage dépend de Commons.

Dans le répertoire principal (maître), j'exécute mvn dependency:tree et voyez:

[INFO] Building system
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] domain:system:pom:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] Building commons
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
...correct tree...
[INFO] ------------------------------------------------------------------------
[INFO] Building storage
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
Downloading: http://my.repo/artifactory/repo/domain/commons/1.0-SNAPSHOT/commons-1.0-SNAPSHOT.jar
[INFO] Unable to find resource 'domain:commons:jar:1.0-SNAPSHOT' in repository my.repo (http://my.repo/artifactory/repo)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) domain:commons:jar:1.0-SNAPSHOT

Pourquoi la dépendance vis-à-vis des "communs" échoue-t-elle, même si le réacteur l'a bien vu car il traite avec succès son arbre de dépendance? Il ne faut certainement pas aller sur le net pour le trouver car il est juste là ...

Le pom pour le stockage:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.Apache.org/POM/4.0.0 http://maven.Apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.Apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <packaging>jar</packaging>
  <parent>
    <artifactId>system</artifactId>
    <groupId>domain</groupId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <groupId>domain</groupId>
  <artifactId>storage</artifactId>
  <name>storage</name>
  <url>http://maven.Apache.org</url>
  <dependencies>
    <!-- module dependencies -->
    <dependency>
      <groupId>domain</groupId>
      <artifactId>commons</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>

    <!-- other dependencies -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Merci pour toutes suggestions!

(Éditer)

Pour clarifier, ce que je recherche ici est le suivant: je ne veux pas avoir à installer le module X pour construire le module Y qui dépend de X, étant donné que les deux sont des modules référencés à partir du même POM parent. Cela a un sens intuitif pour moi que si j'ai deux choses dans la même arborescence source, je ne devrais pas avoir à installer des produits intermédiaires pour continuer la construction. J'espère que ma pensée a un certain sens ici ...

javamavenmaven-2dependencies
84
Steven Schlansker

Je pense que le problème est que lorsque vous spécifiez une dépendance, Maven s'attend à ce qu'elle soit sous forme de pot (ou autre) emballée et disponible à partir d'au moins un dépôt local. Je suis sûr que si vous exécutez mvn install sur votre projet commun d'abord tout fonctionnera.

19
Bostone

Comme indiqué dans ce fil de la liste de diffusion maven , l'objectif de dépendance: arborescence recherchera lui-même les choses dans le référentiel plutôt que dans le réacteur. Vous pouvez contourner ce problème en installant mvn, comme suggéré précédemment, ou en faisant quelque chose de moins onéreux qui appelle le réacteur, comme

mvn compile dependency:tree

Travaille pour moi.

93
Don Willis

Se rendre compte que c'est un fil plus ancien mais il semble que l'outil ait évolué ou que cela ait pu être manqué la première fois.

Il est possible d'effectuer une construction qui résout les dépendances sans installer en faisant une construction de réacteur.

Si vous démarrez votre build dans le parent qui décrit la structure des modules de votre projet, vos dépendances entre vos modules seront résolues lors de la build elle-même via le réacteur Maven interne.

Bien sûr, ce n'est pas la solution parfaite car elle ne résout pas la construction d'un seul module individuel au sein de la structure. Dans ce cas, Maven n'aura pas les dépendances dans son réacteur et cherchera à le résoudre dans le référentiel. Ainsi, pour les versions individuelles, vous devez toujours installer les dépendances en premier.

Voici quelques référence décrivant cette situation.

6
Newtopian

pour moi, ce qui m'a conduit à ce fil était un problème similaire et la solution était de s'assurer que tous les pom de dépendance de module avaient

 <packaging>pom</packaging>

le parent avait

pom

mon modèle dep avait pom - donc il n'y avait pas de pot à trouver.

3
bsautner

La seule chose qui a fonctionné pour moi: passer à gradle :(

J'ai

Parent
  +---dep1
  +---war1 (using dep1)

et je peux simplement cd dans war1 et utiliser mvn Tomcat7: run-war. Je dois toujours installer tout le projet avant, malgré les références war1 à son parent et les références parent war1 et dep1 (en tant que modules), toutes les dépendances doivent donc être connues.

Je ne comprends pas quel est le problème.

3
mba

Dans une structure de module Maven comme celle-ci:

- parent
  - child1
  - child2

Vous aurez dans le parentpom ceci:

<modules>
  <module>child1</module>
  <module>child2</module>
</modules>

Si vous dépendez maintenant de child1 Dans child2 En mettant ce qui suit dans votre <dependencies> Dans child2:

<dependency>
  <groupId>example</groupId>
  <artifactId>child1</artifactId>
</dependency>

Vous recevrez une erreur indiquant que le fichier JAR pour child1 Est introuvable. Cela peut être résolu en déclarant un bloc <dependencyManagement> Incluant child1 Dans le pom pour parent:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>example</groupId>
      <artifactId>child1</artifactId>
      <version>${project.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>

child1 Sera désormais généré lorsque vous exécuterez un objectif compile ou package etc. sur parent, et child2 Trouvera child1.

0
bothor

Bonus sur le réponse de Don Willis :

Si votre build crée des pots de test pour partager le code de test entre vos sous-modules de réacteur, vous devez utiliser:

mvn test-compile dependency:tree

qui permettra dependency:tree pour s'exécuter complètement dans ce cas.

0
adrock20