Maven не розпізнає модулі братів або сестер під час запуску залежності mvn: дерево

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

У мене є:

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

у батьківському POM (який має pom типу пакувального типу), а потім підкаталогах, commons/і storage/які визначають JAR poms з тим самим іменем.

Зберігання залежить від Commons.

У головному (головному) каталозі я запускаю 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. Для мене це інтуїтивно зрозуміло, що якщо у мене є дві речі в одному дереві джерел, мені не потрібно встановлювати проміжні продукти, щоб продовжувати збірку. Сподіваюся, моє мислення має тут якийсь сенс ...

Я думаю, проблема полягає в тому, що коли ви вказуєте залежність, Maven розраховує мати її як jar (або що завгодно), упаковану та доступну принаймні з локального репо. Я впевнений, що якщо ви запустите mvn installсвій спільний проект, спочатку все запрацює.

Як обговорювалось у цьому потоці списку розсилки maven , мета залежності: дерево сама по собі буде шукати речі у сховищі, а не в реакторі. Ви можете обійти це, встановивши mvn, як було запропоновано раніше, або зробивши щось менш обтяжливе, що викликає реактор, наприклад

mvn compile dependency:tree

Працює для мене.

Розуміючи, що це старіший потік, але, схоже, або інструмент еволюціонував, або це можливо було пропущено вперше.

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

Якщо ви починаєте свою збірку в батьківському, що описує структуру модулів вашого проекту, ваші залежності між вашими модулями будуть вирішені під час самої збірки за допомогою внутрішнього реактора Maven.

Звичайно, це не ідеальне рішення, оскільки воно не вирішує побудову окремого окремого модуля в структурі. У цьому випадку Мейвен не матиме залежностей у своєму реакторі і буде прагнути вирішити це питання у сховищі. Отже, для окремих збірок вам все одно доведеться спочатку встановлювати залежності.

Ось кілька посилань, що описують цю ситуацію.

для мене те, що привело мене до цього потоку, було подібною проблемою, і рішенням було забезпечити всі залежності модулів pom

 <packaging>pom</packaging>

батько мав

пом

у моєї моделі деп був пом - тому жодної банки не було знайдено.

Єдине, що мені вдалося: перехід на gradle :(

У мене є

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

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

Я не розумію, в чому проблема.

У такій структурі модуля Maven:

- parent
  - child1
  - child2

У вас буде в parent pomцьому:

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

Якщо ви тепер залежате від child1in child2, вкладаючи в ваш <dependencies>in child2:

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

Ви отримаєте повідомлення про помилку, для якого child1неможливо знайти JAR . Це можна вирішити, оголосивши <dependencyManagement>блок, що включає child1в pomдля parent:

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

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

Bonusing від відповіді від Дона Вілліса :

Якщо ваша збірка створює тестові банки для обміну тестовим кодом між вашими підмодулями реактора, вам слід використовувати:

mvn test-compile dependency:tree

що дозволить dependency:treeу цьому випадку працювати до кінця.

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