В настоящее время я пытаюсь выяснить, как будет работать рабочий процесс Ivy при создании тегов VC (мы используем SVN, но это не имеет значения).Как работает Ivy с контролем версий Tags

Дело в том, что мы разработали несколько библиотек, которые зависят друг от друга. Чтобы облегчить разработку, тег зависимости в пределах ivy.xml имеет атрибут rev, установленный на latest.integration.

<dependencies> 
    <dependency org="my-company" name="my-lib" rev="latest.integration"/> 
</dependencies>

Это было на самом деле результат форма this question на StackOverflow. Это помогает нам быстро вносить изменения в одну библиотеку и запускать единичный тест в нашем основном приложении без необходимости вручную изменять ревизию.

После того, как разработка завершена, мы публикуем библиотеки для внутреннего репозитория Ivy и создаем тег SVN.

Проблема возникает в том, что после того, как нам нужно перестроить программное обеспечение из тега, Ivy по-прежнему указывает на latest.integration, который в более поздний момент, скорее всего, укажет на еще одну сборку интеграции, возможно, даже на более позднюю публикацию версии (в зависимости от конфигурации преобразователя).

Теперь этот вопрос очевиден: что является лучшим способом разрешить Ivy для опубликованных изменений, которые были integration.latest на момент создания тега VCS. И было бы очень полезно, если бы ответ «не вводил опубликованные изменения вручную, прежде чем создавать тег». Может быть, мне нужно добавить что-то в сценарий сборки ANT, возможно, некоторые изменения в моих settings.xml или ivy.xml.

Поскольку Айви довольно умный и удобный маленький инструмент, я думаю, там должен быть способ сделать это ...

источник

2014-09-15 jaw

Плющ deliver task используется для создания разрешенную файла плющ от оригинала проекта. Под «разрешенным» я имею в виду файл, пригодный для публикации в удаленном репозитории. Это означает, что не только разрешены динамические зависимости, в модуле info tag установлены дополнительные атрибуты ревизии и состояния.

В следующем примере создается файл ivy.xml в директории для сборки:

<ivy:deliver deliverpattern="${build.dir}/ivy.xml" pubrevision="${project.version}" status="release"/>

Проверьте файл вы обнаружите зависимость версии набора.

На этом этапе стоит отметить, что эта способность является одним из тонких, но важных точек, отделяющих плющ от Maven. Ivy позволяет вашей автоматизированной системе выпуска просто создавать теги и запускать сборку.Посмотрите на извитых шагах, необходимого Maven и автоматизируемых это release plugin:

Убедитесь, что нет никаких неподтвержденных изменений в источниках
Проверить, что нет МГНОВЕННЫХ зависимостей
Изменения версии в РОМ от х SNAPSHOT до новой версии (вам будет предложено для версий использовать)
преобразования информации SCM в POM, чтобы включить в конечный пункт назначения тега
Выполнить испытание проекта против модифицированного РОМА в подтвердить, что все в рабочем состоянии
Commit Модифицированный РОМ
Тег кода в SCM с именем версии (это будет предложено)
Bump версии в РОМ на новое значение у-снимку (эти значения будут также будет предложено ввести)
Commit модифицированного РОМА

Граф внимательно .... Это 2 фиксаций и операцию тегов ..... Все потому, что модуль версия Maven является обязательной, и мы пытаемся захватить в SCM разрешенные зависимости ....

Итак, мой совет должен быть осторожным с эмулированием Maven. Когда я помещаю свой код, я фиксирую момент времени, когда создаю код. Я полагаюсь на то, что файл плюща, перенесенный в мой удаленный репозиторий, полностью разрешен. Разумеется, параноик мог бы сохранить локальную копию этого плющ-файла, но никогда не был бы файлом, который использовался для создания оригинала. На практике никогда невозможно воспроизвести исходный двоичный код, просто что-то приближенное к нему.

Дополнительная информация

Чтобы понять, как доставить используется задача, следующие примеры показывают, как он используется для создания решены Maven POM файлы при публикации ANT артефактов в хранилище Maven как Nexus:

источник

2014-09-16 01:26:51

Спасибо Марку. Я думаю, что задача доставки - именно то, что я хочу. Вы писали, что полагаетесь на опубликованные версии. Но в нашем случае мы не публикуем основное исполняемое приложение для репо, потому что оно никогда не будет разрешено кем бы то ни было. Поэтому мне, вероятно, не нужны «доставленные» файлы ivy.xml для libs, а для основного приложения. – jaw

Однако я до сих пор не знаю, как выглядит рабочий процесс. Моим attemp было бы создание задачи ANT, которая создает «ivy-deliver.xml» в корне проекта, который будет проверен в репозитории VC. Затем, всякий раз, когда нужно воспроизвести помеченную версию, поставляемый xml будет использоваться для перезаписывания ivy.xml, а затем будет создано приложение. Это имеет смысл? – jaw

@jaw Да, конечно, имеет смысл. Вы сохраняете «плющ-доставленный.xml» в Subversion, чтобы воссоздать сборку, в случае стихийного бедствия. Я использую альтернативный подход к использованию файла «ivy.xml», хранящегося в моем репозитории выпуска. В моем случае я использую Nexus в качестве хранимого в версиях хранилища всех моих исполняемых файлов релиза (и зависимостей этих двоичных файлов). Я помещаю свой репозиторий исходного кода, чтобы я мог видеть источник, который использовался для создания двоичного файла. Для меня было бы редким событием, вынужденным перестроить выпуск. Как указано, ухаживатель не может произвести * точно * тот же самый файл. –

Как работает Ivy с контролем версий Tags

ответ

Дополнительная информация

Смежные вопросы