Как использовать версии интеграции ivy со старыми версиями кода?

Моя организация рассматривает возможность использования Apache Ivy для управления зависимостями в многопроектной конфигурации. У нас есть основной проект (назовем его MAIN), в котором происходит большая часть разработки, и несколько проектов вспомогательных библиотек (назовем его LIBPROJ), которые мы храним в отдельных репозиториях. Что мы делаем прямо сейчас, так это собираем jar-файлы для проектов библиотек, когда они изменяются, и фиксируем их в основном проекте, но это большая головная боль и приводит к раздуванию проекта.

Похоже, что использование чего-то вроде плюща хорошо подходит. Мы предполагаем использовать наш сервер Jenkins для автоматического создания новой библиотеки JAR для LIBPROJ и публикации ее на ivy, а затем использовать версию «latest.integration» для автоматического добавления последней версии LIBPROJ в MAIN. Но если нам нужно разделить пополам, чтобы узнать, когда возникла проблема, как это может работать?

Единственный способ, который я могу придумать, сделать это прямо сейчас — изменить версию LIBPROJ, от которой мы зависим, в MAIN всякий раз, когда в LIBPROJ вносятся изменения, но это не намного лучше, чем проверка в самой банке.

Причина, по которой я беспокоюсь об этом, заключается в том, что в случае просмотра старых версий MAIN, если я просто проверю одну из них, ее невозможно будет собрать и запустить, потому что она запрашивает последнюю сборку, даже несмотря на ту версию, которую я м, на которые я смотрю прямо сейчас, может рассинхронизироваться на дни/недели/месяцы. Это сломает любые инструменты разделения пополам (например, в git или mercurial), чего я действительно не хочу делать.


person QuercusMax    schedule 27.07.2012    source источник


Ответы (2)


Использование динамических редакций — нормальная и мощная функция ivy. Очевидно, вам нужно быть осторожным, потому что зависимости новых сборок потенциально могут дать сбой, когда сторонние проекты вносят несовместимые изменения.

Мои рекомендации по использованию:

  • latest.release: для модулей, произведенных одной и той же компанией (или сотрудничающими компаниями).
  • latest.integration: для модулей, созданных другими командами в рамках одного проекта.

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

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

Наконец, если у вас есть опасения по поводу того, как воспроизвести старые сборки, доступное решение — зафиксировать копию разрешенного ivy.xml при сокращении выпуска. Это может сделать задача доставки ivy.

<ivy:deliver deliverpattern="ivy-resolved.xml" pubrevision="${version}" status="release"/>

И не забывайте, что если вы опубликуете модуль в своем репозитории ivy, там также будет копия разрешенного файла ivy.

person Mark O'Connor    schedule 27.07.2012

Из-за вашего последнего замечания вам не следует использовать last.integration. ИМХО, последняя концепция особенно полезна между проектами в одних и тех же репозиториях, где вы ожидаете клонировать/извлекать их вместе.

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

вы можете создать скрипт, который (не мой любимый):

1) собирает библиотеки LIBPROJ

2) затем извлеките основной и измените его версии зависимостей.

Я, однако, не поощрял это, когда представлял IVY своим коллегам. Если вам нужна новая версия LIBPROJ, создайте ее и отправьте с четким выпуском.

Затем измените файл зависимостей в вашем MAIN.

1) Он не будет раздувать двоичные файлы.

2) создает ощущение отслеживания того, какая версия используется сейчас.

3) Версионирование.

person Eyad Ebrahim    schedule 27.07.2012