Maven non riconosce i moduli di pari livello durante l'esecuzione di mvn dependency: tree

Sto cercando di impostare un progetto Maven multi-modulo e le dipendenze tra moduli apparentemente non vengono impostate correttamente.

Io ho:

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

nel POM genitore (che ha un pom di tipo packaging) e poi sottodirectory commons/e storage/che definiscono poms JAR con lo stesso nome.

Lo spazio di archiviazione dipende da Commons.

Nella directory principale (master), corro mvn dependency:treee vedo:

[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

Perché la dipendenza dai "comuni" fallisce, anche se il reattore lo ha ovviamente visto perché elabora con successo il suo albero delle dipendenze? Non dovrebbe assolutamente andare in rete per trovarlo perché è proprio lì ...

Il pom per la conservazione:

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

Grazie per eventuali suggerimenti!

(Modificare)

Per chiarire, quello che sto cercando qui è questo: non voglio dover installare il modulo X per costruire il modulo Y che dipende da X, dato che entrambi sono moduli referenziati dallo stesso POM genitore. Questo ha un senso intuitivo per me che se ho due cose nello stesso albero dei sorgenti, non dovrei dover installare prodotti intermedi per continuare la compilazione. Spero che il mio pensiero abbia un senso qui ...

Penso che il problema sia che quando si specifica una dipendenza Maven si aspetta di averla come jar (o qualsiasi altra cosa) confezionata e disponibile almeno da un repository locale. Sono sicuro che se corri prima mvn installsul tuo progetto commons tutto funzionerà.

Come discusso in questo thread della mailing list esperto , l'obiettivo dependency: tree da solo cercherà le cose nel repository piuttosto che nel reattore. Puoi aggirare questo problema installando mvn, come suggerito in precedenza, o facendo qualcosa di meno oneroso che invoca il reattore, come

mvn compile dependency:tree

Per me va bene.

Rendendosi conto che questo è un thread più vecchio, ma sembra che lo strumento si sia evoluto o che questo potrebbe essere stato perso la prima volta.

È possibile eseguire una compilazione che risolva le dipendenze senza installare eseguendo una compilazione del reattore.

Se avvii la build nel genitore che descrive la struttura del modulo del tuo progetto, le tue dipendenze tra i tuoi moduli verranno risolte durante la build stessa attraverso il reattore Maven interno.

Ovviamente questa non è la soluzione perfetta poiché non risolve la costruzione di un singolo modulo individuale all'interno della struttura. In questo caso Maven non avrà le dipendenze nel suo reattore e cercherà di risolverlo nel repository. Quindi per le build individuali devi ancora installare prima le dipendenze.

Ecco alcuni riferimenti che descrivono questa situazione.

per me, ciò che mi ha portato a questo thread è stato un problema simile e la soluzione è stata quella di garantire che tutte le dipendenze dai moduli di pom

 <packaging>pom</packaging>

il genitore aveva

pom

il mio dipendente modello aveva il pom - quindi non c'era nessun barattolo da trovare.

L'unica cosa che ha funzionato per me: passare a gradle :(

io ho

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

e posso semplicemente cd in war1 e usare mvn tomcat7: run-war. Devo sempre installare l'intero progetto prima, nonostante war1 faccia riferimento al suo genitore e il genitore fa riferimento a war1 e dep1 (come moduli), quindi tutte le dipendenze dovrebbero essere conosciute.

Non capisco qual è il problema.

In una struttura del modulo Maven come questa:

- parent
  - child1
  - child2

Avrai in parent pomquesto:

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

Se ora dipendi da child1in child2inserendo quanto segue nel tuo <dependencies>in child2:

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

Riceverai un errore per il quale child1non è possibile trovare il JAR . Questo può essere risolto dichiarando un <dependencyManagement>blocco incluso child1in pomfor parent:

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

child1ora verrà compilato quando esegui un obiettivo compileo packageecc. parente child2troverà child1i file compilati di.

Bonificando la risposta di Don Willis :

Se la tua build crea barattoli di prova per condividere il codice di prova tra i sottomoduli del tuo reattore dovresti usare:

mvn test-compile dependency:tree

che consentirà dependency:treein questo caso di essere completato.

Assicurati che il modulo che sta fallendo venga risolto nel pom, stia puntando al genitore giusto includendo le configurazioni nel file pom del modulo.