Установка сторонних JAR-файлов в рамках жизненного цикла Maven и зависимости от системы

Question

Мой проект зависит от некоторых сторонних JAR, которые недоступны в Maven Central.

Большая часть информации, которую я вижу относительно этой ситуации, включая официальное руководство Maven по установке сторонних JAR , рекомендует установить артефакт в локальный репозиторий, используя mvn install:install-file .... Это хорошо работает при локальной разработке, но когда сборка должна выполняться на многих различных системах в автоматическом режиме, этот шаг вручную нежелателен и нецелесообразен.

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

Поскольку ни один из этих вариантов не является приемлемым, я могу представить два варианта:

1. Сохраните JAR в каталоге lib внутри проекта и объявите зависимость с областью system (как предложено в нескольких ответов ). Казалось бы, это работает на любой системе, поскольку зависимость связана с проектом, но я видел, что использование system не рекомендуется как плохая практика (обычно без объяснения причин).
2. Свяжите maven-install-plugin с фазой жизненного цикла initialize, чтобы установить артефакт в локальный репозиторий. Однако, как указано здесь , это приведет к ненужным накладным расходам, поскольку выполняется для каждой сборки. Если бы был способ выполнить это лениво, только если артефакт не установлен, это было бы идеально.

Мне бы хотелось, чтобы стандартный проект Maven мог быть построен с использованием обычного жизненного цикла Maven, без каких-либо дополнительных шагов "run scripts / init-dependencies first".

Как лучше всего двигаться вперед?

Answer 1

Вот недавний ответ на этот вопрос: Maven: хранение зависимых jar-файлов в управлении версиями проекта

Я не рекомендую использовать install-file в жизненном цикле. Как вы упомянули, он будет запускаться каждый раз - вышеупомянутое решение пропустит проект довольно быстро. Хотя вышеприведенное создает новый модуль, оно уменьшает многословность, необходимую для многих JAR-файлов, позволяет использовать формат репозитория, который можно легко скопировать в диспетчер репозитория, и исключает его из основной сборки.

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

Answer 2

Я бы создал задачу ant для проверки файла .mylibisinstalled.Если он не существует, mvn установите yourlib.jar и создайте его.

Затем вы можете связать эту задачу ant с фазой инициализации maven - накладные расходы будут минимальными.

Этонемного хакерский, но у вас есть некоторые ограничения.

Answer 3

Если бы был способ выполнить это лениво, только если артефакт не установлен, это могло бы быть идеально.

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

Создайте отдельный профиль для установки библиотек и привязки maven-install-plugin, как предложено в вашем вопросе.

Вы можете активироватьпрофиль вручную с помощью -P myprofile.Другой вариант, если вы хотите стать на 100% взломанным, - это адаптировать @vlf "check for file" для чистого Maven.Просто используйте триггер активации для профиля.Может быть что-то вроде этого ( ПРЕДУПРЕЖДЕНИЕ : не проверено):

<activation>
  <file>
    <missing>${user.home}/.myapp/.mylibisinstalled</missing>
  </file>
</activation> 

Если у вас есть общий набор библиотек, которые используются во многих проектах, просто создайте отдельный установщик артефакт с собственным pom.xml.Таким образом, вам не нужно носить одинаковые файлы JAR для нескольких проектов.

У меня лично есть install-extra-libs артефакт с этой целью.Он содержит несколько jar-файлов в папке lib (а также несколько jar-файлов javadocs и исходного кода), некоторые зависимости от скрытых / защищенных паролем репозиториев, и даже загружает некоторые файлы напрямую, используя antrun: run и ANT получить задание .Для папки lib и загруженных jar существует несколько крупных install-file ставок.Это уродливо и хакерски, но работает, когда вам обычно приходится многократно устанавливать один и тот же набор библиотек / javadocs в несколько репозиториев.

PROS:

• Вся хакерская атака происходит внутри этого артефакта.В моих проектах используется чистый синтаксис зависимостей.
• Нет дублирования файлов JAR.Нет файлов JAR в SCM.
• Я считаю, что это способ создания новых хранилищ Maven "на лету".

CONS:

• Это побеждает цель Maven.Если вы делаете это для общедоступных проектов с открытым исходным кодом, рассмотрите возможность загрузки его в общедоступный репозиторий и синхронизации с Maven Central ... Вот руководство , объясняющее, как это сделать из репозитория Sonatype.Это займет некоторое время, но по крайней мере другие люди могут извлечь выгоду из ваших усилий.
• Это побеждает цель Maven x2.Если вы не будете осторожны, вскоре вы потеряете информацию о том, какие зависимости находятся в Центральном хранилище.В большинстве моих проектов используется одна или несколько пользовательских установленных зависимостей, поэтому любой из них будет публичным.

Приветствия,