Интеграция Maven с плющом

• Перенесите репозиторий в Maven (например, Nexus), поскольку Ivy может легко использовать репозитории в стиле Maven (так что ваши клиенты Ivy могут продолжать использовать Ivy с некоторыми небольшими изменениями конфигурации, и клиенты Maven также будут работать — также потребности процесса push-to-repo) быть измененным)
• Попробуйте JFrog Artifactory, поскольку он, как сообщается, может обслуживать одни и те же ресурсы как для Ivy, так и для Maven (заявление об отказе: на самом деле я не пытался использовать его и не знаю, включает ли эта версия в Open Source эту функцию или нет)
• или читать дальше …

Моя цель для решения (как бы сложного это ни было) была:

• Это должно быть как можно проще и понятнее
• Это должно уважать принцип СУХОГО (не повторяйте себя)
• У него не должно быть других зависимостей, кроме самого Maven.

Решение выглядит следующим образом (полный исходный код смотрите в репозитории ):

Иметь два профиля Maven: ivy-dependencies активируется, когда зависимости уже были загружены, и ivy-resolv, когда еще предстоит загрузить. Это основано на проверке каталога, куда в конечном итоге должны быть скопированы зависимости:

К сожалению, здесь есть небольшое повторение, поскольку Maven, похоже, не раскрывает пользовательские свойства, такие как $ {ivy.target.lib.dir} в разделе активации профиля. Профили также выполняют другую роль: избегать рассмотрения зависимостей до их фактического разрешения.

Когда сборка запускается впервые, она создает целевой каталог и записывает туда файлы, необходимые для сборки Ivy (ivy.xml, ivysettings.xml и build.xml — для этого примера я использовал некоторые части из соответствующих файлов Red5 repo ), запускает сборку и пытается очистить после себя. Он также создает файл dependencies.txt, содержащий фрагмент текста, который необходимо добавить в список зависимостей. Наконец, он выдает (терпит неудачу) указание пользователю выполнить команду снова.

При втором (третьем, четвертом и т. Д.) Запуске зависимости уже будут присутствовать, поэтому процесс разрешения не будет выполняться беспрепятственно. Этот подход был выбран вместо запуска разрешения при каждой сборке, потому что — хотя процесс разрешения быстрый и быстрый — в некоторых более сложных случаях это может занять десятки секунд, и я не хотел замедлять сборку.

Иви, инфраструктура Apache BSF и т. Д. Извлекаются из центрального хранилища Maven, поэтому их не нужно предварительно устанавливать для успешного завершения сборки.

Пару слов о выборе $ {ivy.target.lib.dir}: если вы выберете его в своем дереве Maven (как это было выбрано в примере), вы получите предупреждение от Maven, что это может не поддерживаться в будущем , Кроме того, обязательно добавьте каталог в механизм игнорирования вашей VCS (.gitignore, .hgignore, .cvsignore, svn: ignore и т. Д.), Чтобы избежать случайной фиксации библиотек в VCS.

Если вам нужно добавить новую (Ivy) зависимость в проект, выполните следующие шаги:

• Удалить текущий каталог $ {ivy.target.lib.dir}
• Обновите часть вашего pom.xml, которая записывает файл ivy.xml, чтобы включить новую зависимость
• Запустите сборку и посмотрите, как разрешается новая зависимость
• Обновите раздел зависимостей в профиле ivy-dependencies, чтобы включить новую зависимость (возможно, копирование из dependencies.txt)

Одним из недостатков этого метода является тот факт, что расширенные функциональные возможности систем на основе Maven не будут работать с этими зависимостями (например, анализ зависимостей / графические плагины, автоматическая загрузка источников / javadocs и т. Д.). Возможный обходной путь (и хорошая идея в целом) состоит в том, чтобы использовать этот метод для минимального подмножества — только банки, которые не могут быть найдены в центральном Maven. Все остатки (даже если они на самом деле являются зависимостями кода, извлекаемого из Ivy) должны быть объявлены как обычные зависимости, которые должны быть извлечены из репозитория Maven.

В заключение я хотел бы сказать, что это усилие еще раз показало мне, насколько гибкими могут быть и Maven, и Ivy / Ant, и прояснило многие случаи (например, как мы убегаем)] внутри CDATA — мы разделили его на две части. Кроме того, его можно дополнительно настроить (например, добавить чистую цель в профиль ivy-resolver, чтобы можно было удалить каталог с помощью mvn clean -P ivy-resol или повторно собрать все загруженные файлы jar в один. например, таким образом, таким образом, избегая необходимости изменять pom-файл каждый раз, когда изменяется список зависимостей Ivy — тогда вновь подписанные JAR-файлы не могут быть повторно объединены, поэтому это также не является универсальным решением).

Справка: Интеграция Maven с Ivy от наших партнеров по JCG в группе пользователей Java в Трансильвании .

Статьи по Теме :

• Услуги, практики и инструменты, которые должны существовать в любом доме разработки программного обеспечения, часть 1
• О доменном дизайне, анемичных моделях доменов, генерации кода, внедрении зависимостей и многом другом…
• OSGi Использование Maven с Equinox
• Модульные подходы Java — Модули, модули, модули
• Аспектно-ориентированное программирование с Spring AspectJ и Maven
• Учебник по интеграции GWT EJB3 Maven JBoss 5.1