В многомодульном проекте maven могу ли я создать модуль для вычисления транзитивных зависимостей на основе DependencyReducedPom другого модуля?

Это кажется простым вопросом, но мне было сложно из-за чрезвычайно строгой парадигмы жизненных циклов и фаз maven:

Предполагая, что в многомодульном проекте maven на разных этапах используется несколько плагинов для перезаписи pom.xml в более эффективные версии, примечательными примерами являются:

  • maven-shade-plugin (если <createDependencyReducedPom> включен): когда необходимо опубликовать затененный uber-jar, плагин может игнорировать зависимости, которые не нужно включать. ВСЕГДА выполнять в фазе пакета.

  • flatten-maven-plugin: позволяет опубликованному pom.xml модуля больше не зависеть от родительского pom, заменяя ссылки на свойства их фактическими значениями. Может выполняться на любом этапе, но для обеспечения совместимости с maven-shade-plugin он также ограничен этапом пакета (см. https://issues.apache.org/jira/browse/MSHADE-323)

Когда они комбинируются с другими модулями, кажется, что механизм сборки реактора maven часто путается с тем, какую версию переписанного pom использовать для вычисления транзитивной зависимости. В идеале следует использовать окончательную версию после этапа упаковки. Но в последней версии maven (3.6.3) он может использовать pom.xml только ДО перезаписи, без уменьшенных зависимостей и всех свойств, которые не заменены должным образом.

Мои вопросы:

  1. В чем смысл этого дизайна? Зачем использовать полусырой pom.xml, когда все плагины явно заменяют его?

  2. Как переопределить это поведение, чтобы окончательная версия pom.xml всегда генерировалась и использовалась, независимо от запрашиваемой цели maven?

ОБНОВЛЕНИЕ 1: на данный момент я использую простой способ обхода:

  • разделение первого модуля на независимый проект maven, при этом плагины maven-shade и flatten-maven вызываются на этапе пакета. (У меня нет прямых доказательств, но я подозреваю, что именно так переупаковываются зависимости, такие как spark-project.hive https://mvnrepository.com/artifact/org.spark-project.hive/hive-common, см. https://issues.apache.org/jira/browse/SPARK-20202. для соответствующего обсуждения)

  • используйте сценарий оболочки для последовательной компиляции/публикации вышеупомянутого проекта и основного многомодульного проекта.

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

Большое спасибо за ваше мнение


maven maven-module maven-shade-plugin maven-dependency flatten-maven-plugin
person tribbloid    schedule 06.09.2020    source источник
comment
Итак, с какой конкретной проблемой вы сталкиваетесь? Почему для вас проблема, если Maven читает POM сборки, а не POM, который окончательно развернут?   -  person J Fabian Meier    schedule 07.09.2020
comment
последствия: 1. IDE будет прикреплять бесполезные банки при выполнении тестов и профилировании. 2. другие плагины в нижестоящих модулях, которые полагаются на транзитивную зависимость как на доказательство, будут вести себя странно. Из-за алгоритма загрузки классов JVM эти проблемы, скорее всего, будут скрыты во время выполнения, но нет никакой гарантии.   -  person tribbloid    schedule 07.09.2020
comment
Извините, я до сих пор не понимаю, почему вам нужен обходной путь и вы не можете просто построить. Не могли бы вы привести конкретный пример того, что пошло не так?   -  person J Fabian Meier    schedule 08.09.2020
comment
Я думаю, это очень помогло бы в вопросе, если бы вы могли добавить конкретный пример.   -  person J Fabian Meier    schedule 14.09.2020

Ответы (1)


arrow_upward
2
arrow_downward

Во-первых: maven's extremely rigorous paradigm of lifecycles and phases: у этих жизненных циклов и фаз есть очень веские причины.

Кроме того, вы упомянули, что несколько плагинов переписывают файл pom.xml. Единственными примерами являются maven-shade-plugin и flatten-maven-plugin, как вы упомянули.

Кроме того, как вы упомянули намерение maven-shade-plugin:

Этот плагин предоставляет возможность упаковать артефакт в uber-jar, включая его зависимости, и затенить — т. е. переименовать — пакеты некоторых зависимостей.

Намерение состоит в том, чтобы затенить зависимости (распаковать jar-файлы и переупаковать их в один jar-файл) и создать исполняемый jar-файл (это также можно сделать с помощью maven-assembly-plugin) этого... не сбрасывать со счетов зависимости.

Идея flatten-maven-plugin состоит в том, чтобы удалить части файла pom, которые не нужны для последующего использования (Создание POM по сравнению с потребительским POM). В настоящее время эта часть станет частью Maven Core с Maven 3.7.0... Это большой первый шаг к разделению сборка pom и потребительский pom.

Итак, давайте перейдем к механизму сборки реактора, который предназначен для определения порядка сборки на основе зависимостей.

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

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

Но в последней версии maven (3.6.3) он может использовать pom.xml только ДО перезаписи, без уменьшенных зависимостей и всех свойств, которые не заменены должным образом.

Это справедливо и для всех предыдущих версий. Кроме того, pom.xml читается в самом начале сборки...

В чем смысл этого дизайна? Зачем использовать полусырой pom.xml, когда все плагины явно заменяют его?

Что именно ты хочешь узнать? Также упоминаются только два плагина (и не все плагины) с разными намерениями.

Как переопределить это поведение, чтобы окончательная версия pom.xml всегда генерировалась и использовалась, независимо от запрашиваемой цели maven?

Нет возможности переопределить это поведение, потому что оно не существует. Это означало бы переписать большую часть ядра Maven.

person khmarbaise    schedule 06.09.2020
comment
...не сбрасывать со счетов зависимости, больше нет, <createDependencyReducedPom> является официальной функцией и включена по умолчанию - person tribbloid; 07.09.2020
comment
К вашему сведению maven.apache.org/plugins/maven-shade -плагин/. Учитывая эту информацию, вы чуть не предположили, что maven - это замок из песка и от него нужно отказаться - person tribbloid; 07.09.2020
comment
Я знаю, что эта опция существует, и цель состоит в том, чтобы удалить зависимости, которые затенены в полученной банке, а не зависимости, которые не используются. В противном случае будет использоваться pom используемого проекта, что было бы неправильно в случае использования плагина maven-shade. Кроме того Considering this information, you almost suggested that maven is a sand castle and should be abandoned Хм... Я не уверен, что вы хотели этим выразить? Где я это предложил/заключил? И я не вижу отношения к заброшенному Maven? - person khmarbaise; 07.09.2020
comment
Извините, я был циником, я не отказываюсь от maven. Однако, чтобы смягчить последствия этой парадигмы (см. мой комментарий к вопросу), теперь мне нужно разбить монолитный проект на 2 и использовать язык клея, чтобы склеить их вместе, чтобы получить правильную версию pom. Должен ли я делать это каждый раз по таким тривиальным причинам? Если язык клея будет распространяться повсюду, превратится ли конвейер сборки в еще одного муравья? Вот вопросы, которые я должен задать в течение следующих 10 лет - person tribbloid; 07.09.2020