Maven не распознает родственные модули при запуске mvn dependency:tree
-
16-09-2019 - |
Вопрос
Я пытаюсь настроить многомодульный проект Maven, и межмодульные зависимости, по-видимому, настроены неправильно.
У меня есть:
<modules>
<module>commons</module>
<module>storage</module>
</modules>
в родительском POM (который имеет pom упаковочного типа)
а затем в подкаталогах commons/
и storage/
которые определяют JAR-poms с тем же именем.
Хранилище зависит от общего доступа.
В главном (master) каталоге я запускаю 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
Почему зависимость от "commons" терпит неудачу, хотя реактор, очевидно, видел это, потому что он успешно обрабатывает свое дерево зависимостей?Он определенно не должен заходить в сеть, чтобы найти его, поскольку он прямо там...
Помпон для хранения:
<?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
сначала в вашем проекте commons все будет работать.
Другие советы
Как обсуждалось в этот поток списка рассылки maven, цель dependency: tree сама по себе будет искать информацию в репозитории, а не в реакторе.Вы можете обойти это, установив mvn, как предлагалось ранее, или выполнив что-то менее обременительное, вызывающее реактор, например
mvn compile dependency:tree
У меня это работает.
Понимаю, что это более старая тема, но, похоже, либо инструмент эволюционировал, либо это, возможно, было упущено в первый раз.
Можно выполнить сборку, которая разрешает зависимости без установки, выполнив сборку реактора.
Если вы начнете свою сборку в родительском файле, который описывает структуру модулей вашего проекта, то ваши зависимости между вашими модулями будут разрешены во время самой сборки с помощью внутреннего Maven reactor.
Конечно, это не идеальное решение, поскольку оно не решает проблему сборки одного отдельного модуля внутри структуры.В этом случае Maven не будет иметь зависимостей в своем реакторе и будет искать решение этой проблемы в репозитории.Таким образом, для отдельных сборок вам все равно придется сначала установить зависимости.
Вот некоторые из них ссылка описываю эту ситуацию.
для меня то, что привело меня к этому потоку, было аналогичной проблемой, и решение состояло в том, чтобы обеспечить наличие всех зависимостей модуля у pom
<packaging>pom</packaging>
у родителя был
пом
у моей модели dep был помпон, так что никакой банки найти не удалось.
Единственное, что сработало для меня :переключение на 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>
Если вы теперь зависите от 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
или package
и т.д.цель на parent
, и child2
найдет child1
это скомпилированные файлы.
Начисление бонусов за счет ответ От Дон Уиллис:
Если ваша сборка создает тестовые банки для совместного использования тестового кода между вашими подмодулями reactor, вам следует использовать:
mvn test-compile dependency:tree
что позволит dependency:tree
чтобы выполнить до завершения в этом случае.
Убедитесь, что модуль, вышедший из строя, был разрешен в pom, указывает на правильного родительского пользователя, включив конфигурации в pom-файл модуля.