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


90

Я пытаюсь настроить многомодульный проект 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. Для меня интуитивно понятно, что если у меня есть две вещи в одном дереве исходных текстов, мне не нужно устанавливать промежуточные продукты для продолжения сборки. Надеюсь, мои мысли здесь имеют какой-то смысл ...


2
Ааа, редактирование отличное. Почему вы не написали это в первом намерении? Также, возможно, подумайте об изменении названия :) Я не хочу быть разборчивым, это просто для ясности и классификации. Это поможет всему сообществу в будущем при поиске аналогичной проблемы (которая не совсем ясна с фактическим названием и содержанием,
касающимся

1
Привет. Вы нашли решение? У меня тоже есть эта проблема :(

1
Компиляция терпит неудачу или только цель dependency: tree? См. Ответ Дона Уиллиса.
metamatt 02

OMG, значит, в одном модуле, если он не работает, потому что он не может найти символы другого модуля, другой должен быть добавлен как зависимость и установлен как JAR? Это ключ ....
WesternGun

печально, что maven 3.6 еще не решает эту проблему
yuxh

Ответы:


21

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


4
Есть ли способ указать, что я хочу, чтобы он использовал ту версию модуля, которая есть в дереве исходных текстов? Я думал, что это дело будет рассмотрено автоматически. Я не хочу / не думаю, что Maven требует выполнять сборку-установку-сборку-установку-сборку каждый раз, когда я просто хочу создать весь проект!
Стивен Шланскер

38
Вы правы, что запущенная установка исправляет это. Однако теперь мне приходится устанавливать каждый раз, когда я вношу изменения, а это не то, что я хочу. Я хочу, чтобы проект хранилища получил последний код из общего проекта.
Стивен Шланскер

Мне действительно приходится сталкиваться с подобными проблемами и, увы, я пока не могу найти ответа. Похоже, Maven не заботится о том, что зависимость связана с вашим модулем, он сразу же отправляется в репо. Ставлю фаворит на твой вопрос - может, ответит какой-нибудь гуру. Мне интересно узнать, можно ли это сделать
Bostone

@Steven Пожалуйста, опубликуйте свою озабоченность как еще один вопрос, на это неудобно отвечать в комментариях, и это другая тема.
Паскаль Тивент 05

6
Это должен был быть главный вопрос, я просто уточнял. Разве я не ясно дал понять в исходном вопросе, что я намерен не требовать, чтобы собранные продукты находились в локальном репозитории для сборки других модулей в том же проекте?
Стивен Шланскер

104

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

mvn compile dependency:tree

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


2
Спасибо за дешевый обходной путь. Но разве это ошибка? Я ожидаю зависимости: цель дерева зависит от реактора без каких-либо уловок.
mcoolive

Следует отметить, что такая же ситуация происходит для любой задачи, которая выполняется глобально, но влияет только на некоторые подпроекты.
tkruse

К сожалению, compileзапускает загрузку транзитивных зависимостей. Есть ли также способ перечислить дерево зависимостей, не загружая их (за исключением, конечно, POM)?
sschuberth

У меня была такая же проблема с другими целями. Добавление compile( validateнедостаточно) помогло и там: mvn compile animal-sniffer:checkиmvn compile org.basepom.maven:duplicate-finder-maven-plugin:check
msa

В зависимости от вашей сборки некоторые модули могут также иметь зависимости от артефактов, которые создаются на более поздних этапах. В моем случае ZIP-файл (с использованием maven-assembly-plugin) был создан packageпоэтапно, поэтому мне нужно было сделать, например mvn package animal-sniffer:check.
msa

6

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

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

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

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

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


1
Есть ли способ создать отдельный модуль без предварительной установки зависимостей и без сборки всего родительского проекта?
ВЫЙТИ - Anony-Mousse

1
Чтобы завершить ответ - если плагин вызывается напрямую (без фаз), например mvn dependency:tree, он все равно не разрешит зависимости от источников, если вы не вызовете compilephase. Так что это будет работать вместо: mvn compile dependency:tree.
Станислав Башкирцев

3

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

 <packaging>pom</packaging>

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

пом

у моего модельного депа был помпон, поэтому баночки не было.


Это вызывает у меня эту ошибку: Ошибка синтаксического анализа при чтении POM. Причина: Нераспознанный тег: «упаковка»
hithwen

edit: я имел в виду, что <packaging> pom </packaging> исправил это. замена <packaging> jar </packaging>
bsautner

4
Это решает проблему, описанную в вопросе, но теперь дочерние модули не создают экспортируемые архивы (т.е. jar-файлы, войны, уши).
sheldonh

sheldonh вы нашли решение для исправления этой ошибки и создали экспортируемый архив?
user3853134

3

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

я имею

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

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

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


1
Вот почему я использую gradle, когда мне нужно создать многомодульный проект. :(
Zhuo YING

2

В такой структуре модуля 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>

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

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

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


2

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

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

mvn test-compile dependency:tree

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


-1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.