Переопределение ревизии зависимостей Ivy - PullRequest
2 голосов
/ 13 сентября 2010

Я использую Apache Ivy для обработки зависимостей библиотеки.В моей компании есть «основной» проект, который периодически выпускается / обновляется.Затем у нас есть много проектов для клиентов, которые предназначены для конкретного клиента.Каждый проект клиента использует определенную версию основного проекта, которую мы поддерживаем в ivy.xml проекта клиента.Все в порядке.

Иногда кто-то захочет изменить ядро ​​локально и протестировать изменение в конкретном проекте.В этом случае они будут собирать ядро ​​и публиковать его в локальном репозитории Ivy, а не в общем.

Для того, чтобы подобрать эту локально собранную версию, мне нужно убедиться, что локально созданная версия или ядропубликуется с той же версией XYZ, на которую указывает проект в ivy.xml?Или есть какой-то другой подход?Я бы предпочел, чтобы люди не требовали возиться с ivy.xml (например, смените его на core -> latest.integration), так как это такое изменение, которое случайно возвращается в систему контроля версий.Может быть, есть какой-то способ переопределить ревизию зависимости в ivy.xml, возможно, в локальном файле свойств?

1 Ответ

1 голос
/ 14 сентября 2010

В процессе разработки я всегда указываю свои внутренние зависимости проекта как «latest.integration» или «latest.release». Это решает проблему не возиться с файлами, проверенными в системе контроля версий.

Хорошая новость заключается в том, что задача ivy publish разрешит вам динамические номера ревизий. Проверьте файл ivy.xml , опубликованный в вашем хранилище, и вы увидите, что последние номера ревизий (на момент публикации) были автоматически заменены.

Задача ivy delivery предназначена для того, чтобы сделать это для вас в вашей сборке. Я использую его, когда мне нужен разрешенный файл плюща для создания POM-файла Maven для моего модуля.

Например:

<ivy:deliver pubrevision="??" status="release" deliverpattern="${build.dir}/ivy.xml"/>
<ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/pom.xml"/>

Мой последний совет - использовать ivy buildnumber , когда вам нужно узнать следующий номер версии в последовательности. Ivy справится с этим на основе того, что уже опубликовано в репозитории ivy (гораздо более гибкий, чем стандартная задача номера сборки ANT, основанная на файлах свойств).

Так что продолжайте использовать динамические ревизии и позвольте Айви определить фактические номера версий в конкретном выпуске.

...