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

J'essaye de mettre en place un projet Maven multi-module, 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 packaging) puis dans les sous commons/- répertoires et storage/qui définissent les poms JAR avec le même nom.

Le stockage dépend de Commons.

Dans le répertoire principal (maître), je cours mvn dependency:treeet vois:

[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 aux «communs» échoue-t-elle, même si le réacteur l'a visiblement vu parce qu'il traite avec succès son arbre de dépendances? Il ne devrait 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 vos suggestions!

(Éditer)

Pour clarifier, ce que je recherche ici est ceci: 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 de produits intermédiaires pour continuer la construction. J'espère que ma réflexion a un sens ici ...

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

Comme discuté dans ce fil de discussion de la liste de diffusion maven , le but dependency: tree en lui-même recherchera 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 invoque le réacteur, tel que

mvn compile dependency:tree

Travaille pour moi.

Réaliser qu'il s'agit d'un thread 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 effectuant une construction de réacteur.

Si vous démarrez votre build dans le parent qui décrit la structure de module de votre projet, vos dépendances entre vos modules seront résolues lors de la construction 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 à les résoudre dans le référentiel. Donc, pour les versions individuelles, vous devez d'abord installer les dépendances.

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

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

 <packaging>pom</packaging>

le parent avait

pom

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

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

j'ai

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

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

Je ne comprends pas quel est le problème.

Dans une structure de module Maven comme celle-ci:

- parent
  - child1
  - child2

Vous aurez dans le parent pomprésent:

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

Si vous comptez maintenant sur child1in child2en mettant ce qui suit dans votre <dependencies>in child2:

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

Vous recevrez une erreur indiquant que le fichier JAR child1est introuvable. Cela peut être résolu en déclarant un <dependencyManagement>bloc incluant child1dans le pomfor parent:

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

child1sera désormais compilé lorsque vous exécuterez un objectif compileou packageetc. sur parent, et child2trouvera child1les fichiers compilés de.

Bonus de la réponse de Don Willis :

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

mvn test-compile dependency:tree

ce qui permettra dependency:treede courir jusqu'à la fin dans ce cas.

Assurez-vous que le module qui échoue est résolu dans le pom, pointe vers le bon parent en incluant les configurations dans le fichier pom du module.