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


90

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 ...


2
Ahhh, le montage est parfait. Pourquoi n'avez-vous pas écrit cela dans la première intention? Aussi, pensez peut-être à changer le titre :) Je ne veux pas être pointilleux, c'est juste pour des raisons de clarté et de classification. Cela aidera toute la communauté à l'avenir lors de la recherche d'un problème similaire (qui n'est pas clair avec le titre et le contenu réels qui concernent la dépendance: tree)
Pascal Thivent

1
Salut. Avez-vous trouvé la solution? J'ai aussi ce problème :(

1
La compilation échoue-t-elle, ou simplement la dépendance: l'objectif de l'arbre seul? Voir la réponse de Don Willis.
metamatt

OMG donc dans un module s'il échoue parce qu'il ne peut pas trouver les symboles d'un autre module, l'autre devrait être ajouté en tant que dépendance et installé en tant que JAR? C'est la clé ....
WesternGun

c'est triste maven 3.6 ne résout pas encore ce problème
yuxh

Réponses:


21

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.


4
Existe-t-il un moyen de spécifier que je souhaite qu'il utilise la version du module dans l'arborescence des sources? Je pensais que ce cas serait traité automatiquement. Je ne veux pas / je ne pense pas que Maven ait besoin de build-install-build-install-build à chaque fois que je veux juste faire tout le projet!
Steven Schlansker

38
Vous avez raison de dire que l'exécution de l'installation le corrige. Cependant, maintenant je dois installer chaque fois que j'apporte des modifications, ce qui n'est pas ce que je veux. Je veux que le projet de stockage récupère le dernier code du projet commun.
Steven Schlansker

En fait, je dois faire face à des problèmes similaires et hélas - je ne suis pas en mesure de trouver une réponse pour l'instant. Il semble que Maven ne se soucie pas que la dépendance soit liée à votre module, elle va juste au dépôt tout de suite. Je vais mettre votre question en favori - alors peut-être qu'un gourou répondra. Je suis intéressé de savoir si cela peut être fait
Bostone

@Steven S'il vous plaît postez votre préoccupation comme une autre question, il n'est pas pratique de répondre dans un commentaire et c'est un autre sujet.
Pascal Thivent

6
C'était censé être la question principale, je clarifiais simplement. N'ai-je pas précisé dans la question initiale que mon intention est de ne pas exiger que les produits construits soient dans le référentiel local pour créer d'autres modules dans le même projet?
Steven Schlansker

104

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.


2
Merci pour cette solution de contournement bon marché. Mais est-ce un bug? J'attends de la dépendance: le but de l'arbre repose sur le réacteur sans aucune astuce.
mcoolive

Il convient de noter que la même situation se produit pour toute tâche exécutée globalement, mais n'affecte que certains sous-projets.
tkruse

Malheureusement, compiledéclenche le téléchargement des dépendances transitives. Existe-t-il également un moyen de lister l'arborescence de dépendances sans les télécharger (sauf les POM, bien sûr)?
sschuberth

J'ai eu le même problème pour les autres buts. L'ajout compile( validatene suffit pas) a également aidé: mvn compile animal-sniffer:checketmvn compile org.basepom.maven:duplicate-finder-maven-plugin:check
msa

En fonction de votre version, certains modules peuvent également avoir des dépendances avec des artefacts générés lors de phases ultérieures. Dans mon cas, un fichier ZIP (utilisant maven-assembly-plugin) a été construit en packagephase, donc je devais faire par exemple mvn package animal-sniffer:check.
msa

6

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.


1
Existe-t-il un moyen de créer un seul module, sans installer les dépendances au préalable et sans créer le projet parent complet?
A QUITTER - Anony-Mousse

1
Pour compléter la réponse - si le plugin est appelé directement (sans phases), par exemple mvn dependency:tree, il ne résoudra toujours pas les dépendances des sources à moins que vous n'appeliez compilephase. Donc , cela fonctionnerait à la place: mvn compile dependency:tree.
Stanislav Bashkyrtsev

3

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.


Cela jette cette erreur pour moi: erreur d'analyse lors de la lecture de POM. Raison:
Balise

edit: je voulais dire <packaging> pom </packaging> corrigé. remplacement de <packaging> jar </packaging>
bsautner

4
Cela résout le problème décrit dans la question, mais maintenant les modules enfants ne produisent pas d'archives exportables (c'est-à-dire jars, wars, oreilles).
sheldonh

sheldonh avez-vous trouvé une solution pour corriger cette erreur et produire une archive exportable?
user3853134

3

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.


1
C'est pourquoi j'utilise gradle lorsque je dois créer un projet multi-module. :(
Zhuo YING

2

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.


2

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.


-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.