- Перенесите репозиторий в Maven (например, Nexus), поскольку Ivy может легко использовать репозитории в стиле Maven (так что ваши клиенты Ivy могут продолжать использовать Ivy с некоторыми небольшими изменениями конфигурации, и клиенты Maven также будут работать — также потребности процесса push-to-repo) быть измененным)
- Попробуйте JFrog Artifactory, поскольку он, как сообщается, может обслуживать одни и те же ресурсы как для Ivy, так и для Maven (заявление об отказе: на самом деле я не пытался использовать его и не знаю, включает ли эта версия в Open Source эту функцию или нет)
- или читать дальше …
Моя цель для решения (как бы сложного это ни было) была:
- Это должно быть как можно проще и понятнее
- Это должно уважать принцип СУХОГО (не повторяйте себя)
- У него не должно быть других зависимостей, кроме самого Maven.
Решение выглядит следующим образом (полный исходный код смотрите в репозитории ):
Иметь два профиля Maven: ivy-dependencies активируется, когда зависимости уже были загружены, и ivy-resolv, когда еще предстоит загрузить. Это основано на проверке каталога, куда в конечном итоге должны быть скопированы зависимости:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
...<id>ivy-dependencies</id><activation> <activeByDefault>false</activeByDefault> <file> <exists>${basedir}/ivy-lib</exists> </file></activation>...<id>ivy-resolve</id><activation> <activeByDefault>false</activeByDefault> <file> <missing>${basedir}/ivy-lib</missing> </file></activation>... |
К сожалению, здесь есть небольшое повторение, поскольку 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