Maven выводит «тестовую» транзитивную зависимость как «компиляцию»

#java #maven #maven-3

#java #maven #maven-3

Вопрос:

Когда я запускаю «mvn dependency: tree» для моего проекта, он показывает следующее:

 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ xxxxx ---
[INFO] com.xxx.xxx:xxxxx:war:3.1.0-SNAPSHOT
...
[INFO]  - commons-configuration:commons-configuration:jar:1.5:compile
[INFO] |  - commons-beanutils:commons-beanutils-core:jar:1.7.0:compile
[INFO]  - org.seleniumhq.selenium:selenium-api:jar:2.34.0:test
[INFO] |   - com.google.guava:guava:jar:14.0:test
[INFO] |  - org.json:json:jar:20080701:test
[INFO]  - org.seleniumhq.selenium:selenium-htmlunit-driver:jar:2.34.0:test
[INFO] |   - org.seleniumhq.selenium:selenium-remote-driver:jar:2.34.0:test
[INFO] |  |   - cglib:cglib-nodep:jar:2.1_3:test
[INFO] |  |   - net.java.dev.jna:jna:jar:3.4.0:test
[INFO] |  |  - net.java.dev.jna:platform:jar:3.4.0:test
[INFO] |  - net.sourceforge.htmlunit:htmlunit:jar:2.12:test
[INFO] |      - org.apache.commons:commons-lang3:jar:3.1:test
[INFO] |      - org.apache.httpcomponents:httpmime:jar:4.2.3:test
[INFO] |      - net.sourceforge.htmlunit:htmlunit-core-js:jar:2.12:test
[INFO] |      - xerces:xercesImpl:jar:2.10.0:test
>>>[INFO] |     |  - xml-apis:xml-apis:jar:1.4.01:compile
[INFO] |      - net.sourceforge.nekohtml:nekohtml:jar:1.9.18:test
[INFO] |      - net.sourceforge.cssparser:cssparser:jar:0.9.9:test
[INFO] |     |  - org.w3c.css:sac:jar:1.3:test
[INFO] |     - org.eclipse.jetty:jetty-websocket:jar:8.1.9.v20130131:test
[INFO]  - org.seleniumhq.selenium:selenium-firefox-driver:jar:2.34.0:test
...
  

Как вы видите в отмеченной строке, xml-api имеет область «компиляции», и в результате он упакован в .файл войны. Почему это могло произойти?

Что более интересно, это происходит только при использовании Java5, для Java6 зависимость отображается как «test».

Версия Maven: 3.0.4

Комментарии:

1. Не xml-api появляется в другом месте как другая зависимость?

2. тестовые зависимости никогда не будут упакованы в war, если вы не сделали что-то странное. Пожалуйста, покажите ваш pom-файл.

3. @khmarbaise Я знаю, но по какой-то причине у меня это есть! Файл pom довольно большой, есть несколько родительских pom… Я не пытался извлечь минимальный образец кода, довольно утомительный, но абсолютно ничего особенного в selenium-htmlunit-driver зависимости, объявленный как обычно.

4. Очень интересно: если я это делаю, mvn dependency:tree это показывает dep как compile , но если я это делаю, mvn -Dverbose dependency:tree dep становится test . Теперь я почти уверен, что это ошибка где-то в maven. В качестве обходного пути я явно объявил xml-apis зависимость в моем pom, кажется, теперь она работает.

5. @SergeBallesta Это не объявлено ни в одном из моих pom. Когда я добавил dep в список исключений selenium-htmlunit-driver , он исчез. Насколько я понимаю, это означает, что это не зависит ни от чего другого.

Ответ №1:

Изучите выходные данные следующей команды Maven.

 mvn -X dependency:tree -Dverbose
  

Это должно объяснить вам, почему Maven обновил область видимости с test до compile.

Ответ №2:

Если вы посмотрите на xercesImpl, он содержит зависимость от xml-api:xml-apis:jar:1.4.01:compile с областью компиляции, поэтому отображение плагина зависимостей корректно. Использование -Dverbose будет выполнять действия, как написано в документах:

Включать ли пропущенные узлы в сериализованное дерево зависимостей.

Помимо вышесказанного, тестовая зависимость, как в вашем случае, никогда не упаковывается в файл war.

Должен быть другой источник той же зависимости, который приводит к упаковке в войну

Кроме того, изменение поведения в связи с добавлением явных xml-api в ваш pom является дополнительным доказательством этого.

Комментарии:

1. Я не думаю, что вы прочитали мой вопрос с полным вниманием. Если вы посмотрите на любую другую тестовую зависимость, например htmlunit , то все ее зависимости указаны как compile, но только xml-api отображаются как compile . -Dverbose Следует просто включать пропущенные узлы (да, это случается), но в моем случае это также меняет область видимости. И .jar упаковывается в war. Есть идеи, как найти «другой источник»? Мои знания Maven говорят мне, что других источников нет.

2. Вы должны начать с вашего артефакта war и посмотреть через mvn dependency: tree, откуда берутся все артефакты.

3. Фрагмент вывода дерева приведен в моем вопросе. Единственный источник, который я вижу, это selenium-htmlunit-driver . И если я <exclude> получаю xml-apis из драйвера, dep исчезает из дерева.

4. Ваш вывод начинается не с war, который, как я упоминал, является отправной точкой такого анализа.

5. ... Означает, что я пропустил много других выходных данных, которые довольно велики и не имеют отношения к вопросу. Я добавил обратно несколько строк для вас.

Ответ №3:

У меня была похожая проблема.

В моем случае запись в dependencyManagement родительского pom устанавливает область действия зависимого артефакта для компиляции. На самом деле я опустил тег scope, который фактически совпадает с настройкой его на компиляцию. Помогло изменение ее на предоставленную. Кажется, область в dependencyManagement имеет приоритет над переходной областью. Что имеет смысл, но все еще может вызвать путаницу, когда все, что вы хотели сделать, это определить версию.

На самом деле это было нетрудно заметить: просмотр effective-pom показал запись dependencyManagement.