Maven non riconosce pari livello moduli durante l'esecuzione di dipendenza mvn: albero

Question

Sto cercando di impostare un progetto Maven multi-modulo, e le dipendenze tra i moduli non sono a quanto pare essere impostato correttamente.

ho:

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

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

bagagli dipende Commons.

Nella directory principale (master), corro mvn dependency:tree e vedere:

[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 da "beni comuni" fallire, anche se il reattore ha ovviamente visto perché elabora con successo il suo albero delle dipendenze? Sicuramente non dovrebbe andare alla 'rete per trovare come è proprio lì ...

Il pom per lo stoccaggio:

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

(Modifica)

Per chiarire, quello che sto cercando qui è questo: io non voglio avere a installare il modulo X per costruire modulo Y che dipende X, dato che entrambi sono i moduli citati dallo stesso POM genitore. Questo ha senso intuitivo per me che se ho due cose nella stessa struttura di origine, non avrei dovuto installare prodotti intermedi per continuare la costruzione. Speriamo che il mio pensiero fa un certo senso qui ...

Answer 1

Credo che il problema è che quando si specifica una dipendenza Maven si aspetta di avere come vaso (o altro) confezionati e disponibile da almeno un repo locale. Sono sicuro che se si esegue mvn install sul progetto Commons prima tutto funzionerà.

Answer 2

Come discusso nel questo esperto di mailing list filo , la dipendenza: obiettivo albero di per sé sarà guardare le cose nel repository piuttosto che il reattore. È possibile aggirare questo problema installando mvn, come suggerito in precedenza, o fare qualcosa di meno oneroso che richiama il reattore, come ad esempio

mvn compile dependency:tree

funziona per me.

Answer 3

Questa scoperta è un filo più vecchio, ma sembra che lo strumento si è evoluto o questo potrebbe essere stato perso al primo giro.

E 'possibile eseguire una generazione che fa le dipendenze risolte senza installare facendo una costruzione del reattore.

Se si avvia il costruire nel genitore che descrive la struttura del modulo del progetto, allora le dipendenze tra i moduli saranno risolti durante la stessa costruzione attraverso il reattore Maven interno.

Naturalmente questo non è la soluzione perfetta in quanto non risolve la costruzione di un singolo modulo individuo all'interno della struttura. In questo caso Maven non avrà le dipendenze nel suo reattore e ape cercando di risolverlo nel repository. Così, per individuo costruisce avete ancora installare le dipendenze prima.

Un po ' riferimento descrivere questa situazione.

Answer 4

per me, quello che mi ha portato a questa discussione è stato un problema simile e la soluzione era quello di garantire tutti i pom modulo di dipendenza ha avuto

 <packaging>pom</packaging>

il genitore aveva

pom

il mio modello dep aveva pom - quindi non c'era vaso da trovare

.

Answer 5

L'unica cosa che workd per me: il passaggio a Gradle: (

ho

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

e posso solo cd in war1 e utilizzare mvn tomcat7: run-guerra. Ho sempre installare l'intero progetto prima, nonostante war1 fa riferimento a suo padre e il padre riferimenti war1 e dep1 (come moduli) in modo da tutte le dipendenze devono essere conosciuti.

Non capisco quale sia il problema.

Answer 6

In una struttura di modulo di Maven in questo modo:

- parent
  - child1
  - child2

Si avrà nel parent pom questo:

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

Se ora dipendono child1 in child2 inserendo la seguente nel tuo <dependencies> in child2:

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

Si riceverà un errore che il JAR per child1 non può essere trovato. Questo può essere risolto dichiarando un blocco <dependencyManagement> compresa child1 nella pom per parent:

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

child1 sarà ora costruire quando si esegue una compile o package ecc gol su parent, e child2 troverà i file compilati di child1.

Answer 7

rispondere da Don Willis :

Se la vostra generazione crea test-giare di condividere il codice di prova tra i vostri sottomoduli del reattore si dovrebbe usare:

mvn test-compile dependency:tree

che permetterà dependency:tree di correre a compimento in questo caso.

Answer 8

Assicurati che il modulo che sta fallendo viene risolto nella POM, è rivolto al genitore destra includendo le impostazioni nel file pom del modulo.