Замяна на ревизия на зависимости на Ivy

Използвам Apache Ivy за обработка на зависимост от библиотека. В моята компания имаме "основен" проект, който се пуска/версира периодично. След това имаме много "клиентски" проекти, които са за конкретен клиент. Всеки клиентски проект използва определена версия на основния проект, която поддържаме в ivy.xml на клиентския проект. Всичко е наред.

Понякога някой ще иска да промени ядрото локално и да тества промяната с конкретен проект. В този случай те ще изградят ядрото и ще го публикуват в локално репо на Ivy, а не в споделеното.

За да взема тази локално изградена версия, трябва ли да се уверя, че локално изградената версия или ядрото се публикува с точно същата x.y.z версия, към която проектът сочи в ivy.xml? Или има някакъв друг подход? Предпочитам хората да не са задължени да се занимават с ivy.xml (напр. да го променят на ядро ​​-> latest.integration), тъй като това е вид промяна, която случайно се регистрира в контрола на източника. Може би има някакъв начин за отмяна на преразглеждането на зависимост в ivy.xml, може би в локален файл със свойства?


dependencies ivy overriding multi-project
person Mike Q    schedule 12.09.2010    source източник

Отговори (1)


arrow_upward
1
arrow_downward

В разработката винаги посочвам моите вътрешни зависимости на проекта като „latest.integration“ или „latest.release“. Това решава проблема с липсата на работа с файловете, проверени в контрола на източника.

Добрата новина е, че задачата на ivy publish ще разрешаване на динамични номера на ревизии вместо вас. Проверете файла ivy.xml, който е публикуван във вашето хранилище, и ще видите, че последните номера на ревизии (към момента на публикуване) са автоматично заменени.

Задачата deliver на ivy е предназначена да прави това за вие в рамките на вашата конструкция. Използвам го, когато имам нужда от разрешен ivy файл, за да генерирам Maven POM файл за моя модул.

Например:

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

Последният ми съвет е да използвате ivy номер на компилация, когато трябва да знаете следващия номер на версия в последователност. Ivy ще реши това въз основа на това, което вече е публикувано в хранилището на ivy (Много по-гъвкаво от стандартната задача за номер на компилация на ANT, която разчита на файлове със свойства).

Така че продължете да използвате динамични ревизии и оставете ivy да изработи действителните номера на версиите в конкретно издание.

person Mark O'Connor    schedule 13.09.2010