Я создаю обычную упаковку Maven на основе жизненного цикла упаковки JAR. Я хотел бы знать, где этот жизненный цикл определен (т. Е. components.xml
местоположение исходного кода).Где определяется срок службы JAR для упаковки Maven?
ответ
У вас есть небольшое заблуждение в вашем вопросе. Упаковка "jar"
не имеет специального жизненного цикла. Он основан на жизненном цикле по умолчанию.
Maven определяет 3 в жизненные циклы
META-INF/plexus/components.xml
:
default
Жизненный циклclean
Жизненный циклsite
Жизненный цикл
Вы можете найти это components.xml
файл в исходном коде here for Maven 3.3.9. default
жизненный цикл не определяет каких-либо привязок, так как они зависят от упаковки:
default
жизненный цикл определяется без любые связанные с этим плагином. Связи с плагинами для этого жизненного цикла: defined separately for every packaging.
Каждая стандартная упаковка (например, "jar"
) определяет плагины, привязанные к определенным этапам этого жизненного цикла по умолчанию. Эти привязки можно найти в файле default-bindings.xml
.
Целью этих двух отдельных файлов является различие между жизненным циклом, который определяет, какие этапы он включает, и упаковкой, которая определяет, какие цели плагина должны быть связаны с этапами этого жизненного цикла.
Спасибо. Мое заблуждение было основано на этой онлайн-книге: https://books.sonatype.com/mvnref-book/reference/lifecycle-sect-package-specific.html В нем используется выражение «Пакет-конкретные Lifecycles», но Я согласен с вашей точкой зрения. –
@FernandoCosta Эта книга Maven - очень хороший ресурс. Да, название «Связанные с пакетом Lifecycles» может немного ввести в заблуждение (потому что это только по умолчанию), но текст после этого правильный. Изменяется конфигурация жизненного цикла, а не самого жизненного цикла. – Tunaki
Конечно, это очень хорошо. Я многому учусь от чтения. –
Почему вы создаете таможенную упаковку? – khmarbaise
Моя команда должна автоматизировать процесс сборки (компиляция, запуск тестов, пакет и развертывание) проектов PL/SQL. Maven достаточно гибкий, чтобы использовать его с не-Java-проектами. Итак, мы начинаем создавать пользовательские плагины и новый тип упаковки. –