Maven не распознает дочерние модули при запуске зависимости mvn: tree

Я пытаюсь настроить многомодульный проект Maven, и межмодульные зависимости, по-видимому, устанавливаются неправильно.

Я имею:

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

в родительском POM (который имеет pom типа упаковки), а затем в подкаталогах commons/ и storage/ которые определяют POM JAR с тем же именем.

Хранение зависит от фонда.

В главном (главном) каталоге я запускаю mvn dependency:tree и вижу:

[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

Почему зависимость от "общего достояния" терпит неудачу, даже если реактор явно ее видел, потому что он успешно обрабатывает свое дерево зависимостей? Это определенно не должно идти в сеть, чтобы найти это как это прямо там...

Пом для хранения:

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

Спасибо за любые предложения!

(Редактировать)

Чтобы уточнить, что я ищу здесь, так это: я не хочу устанавливать модуль X для сборки модуля Y, который зависит от X, учитывая, что оба модуля являются ссылками из одного и того же родительского POM. Для меня это интуитивно понятно, что если в одном дереве исходных текстов есть две вещи, мне не нужно устанавливать промежуточные продукты для продолжения сборки. Надеюсь, мое мышление имеет смысл здесь...

ОТВЕТЫ

Ответ 1

Я думаю, проблема заключается в том, что когда вы указываете зависимость, Maven ожидает, что она будет использоваться как банку (или что-то еще), упакованную и доступную, по крайней мере, из локального репо. Я уверен, что если вы запустите mvn install в своем проекте commons, сначала все будет работать.

Ответ 2

Как обсуждалось в этом потоке рассылки для maven, цель зависимости: tree сама по себе будет выглядеть в репозитории, а не в реакторе. Вы можете обойти это путем установки mvn, как ранее предполагалось, или сделать что-то менее обременительное, которое вызывает реактор, например

mvn compile dependency:tree

Работает для меня.

Ответ 3

Понимая, что это более старый поток, но кажется, что либо инструмент развился, либо это могло быть пропущено в первый раз.

Можно выполнить сборку, которая позволяет решить проблемы без установки путем сборки реактора.

Если вы начнете сборку родителя, которая описывает структуру модуля вашего проекта, ваши зависимости между вашими модулями будут разрешены во время самой сборки через внутренний реактор Maven.

Конечно, это не идеальное решение, поскольку оно не решает сборку отдельного отдельного модуля внутри структуры. В этом случае у Maven не будет зависимостей в его реакторе, и он будет искать решение в репозитории. Поэтому для отдельных сборок вам все равно придется сначала устанавливать зависимости.

Вот несколько ссылка, описывающая эту ситуацию.

Ответ 4

для меня, что привело меня к этой теме, была аналогичная проблема, и решение заключалось в том, чтобы гарантировать, что всякая зависимость модуля pom была

 <packaging>pom</packaging>

у родителя была

POM

У моей модели dep был pom - поэтому не было найденной банки.

Ответ 5

Единственное, что работает для меня: переход на gradle: (

У меня

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

и я могу просто cd в war1 и использовать mvn tomcat7: run-war. Мне всегда нужно установить весь проект раньше, несмотря на то, что war1 ссылается на его родительскую и родительскую ссылки war1 и dep1 (в виде модулей), поэтому все зависимости должны быть известны.

Я не понимаю, в чем проблема.

Ответ 6

В структуре модуля Maven:

- parent
  - child1
  - child2

Вы будете иметь в parent pom это:

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

Если вы теперь зависите от child1 в child2, добавив следующее в ваш <dependencies> в child2:

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

Вы получите ошибку, что JAR для child1 не может быть найден. Это можно решить, объявив блок <dependencyManagement> включающий child1 в pom для parent:

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

child1 теперь будет compile когда вы запускаете цель compile package и т.д. для parent, а child2 найдет скомпилированные файлы child1.

Ответ 7

Бонус от ответа от Дона Уиллиса:

Если ваша сборка создает тестовые jar файлы для совместного использования тестового кода между вашими подмодулями реактора, вы должны использовать:

mvn test-compile dependency:tree

что позволит dependency:tree работать до конца в этом случае.

Ответ 8

Убедитесь, что неисправный модуль разрешен в pom, и указывает на правого родителя, включив конфигурации в pom файл модуля.