Плющ: разрешение и публикация файлов JAR на местном уровне - PullRequest
7 голосов
/ 15 января 2012

Мы использовали Ivy в течение нескольких месяцев и разместили свой собственный «Ivy Repo» на веб-сервере здесь, в офисе. Все наши проекты настроены на использование этого репозитория для разрешения зависимостей.

У нас есть несколько JAR-файлов типа "commons", которые используются во многих наших проектах. Из-за этого и из-за того, что у нас всего 1 репо, мы находим много уродливых накладных расходов из-за следующего сценария:

  • Разработчику дано задание добавить функцию в Project 1 (зависит от Common jar)
  • В ходе разработки Проекта 1 разработчик понимает, что ему / ей необходимо внести изменения в Общую банку
  • Произведены общие замены банок
  • Обычная банка должна пройти проверку кода и нормальное продвижение кода
  • Мастер сборки публикует новую банку Common
  • Проект 1 может возобновить разработку после обновления Common jar

Это становится смешным и болезненным для нашей команды.

Для меня очевидным решением является предоставление в каждом проекте целевых объектов ant, которые позволяют разработчику публиковать / разрешать локально (в свою файловую систему и из нее). Таким образом, они могут разбить банку Common на 9 путей к воскресенью, но не теряя 2–4 дня, ожидая публикации Common. Таким образом, разработчик вносит локальные изменения как в Project 1, так и в Common, и код проходит весь процесс продвижения сразу.

Я знаю, что это возможно с Айви, но я настолько новичок в этом, что даже не знаю, с чего начать.

В настоящее время мы используем глобальный ivy.settings файл для всех проектов. В файле настроек мы используем цепочку разрешений, внутри которой есть 1 преобразователь URL, который подключается к нашему «репозиторию ivy».

Я верю единственное изменение, которое будет необходимо, - это следующее, но я не уверен на 100%:

  • В ivy.settings нам потребуется добавить распознаватель локальной файловой системы до того, как будет вызван распознаватель URL; таким образом, мы проверяем локальную файловую систему на наличие зависимостей, прежде чем перейти к репозиторию ivy (веб-сервер)
  • Сконфигурируйте ivy.xml каждого проекта с опцией, позволяющей публиковать локальный кеш
  • Настройте сборку Муравья, чтобы иметь цель publish-locally, которая использует опцию, упомянутую выше

Я полагаю , что эти изменения позволят нам: (1) всегда искать локально на предмет зависимостей перед обращением к веб-серверу, (2) публиковать локально как параметр сборки (цель).

Если это не так, или если я пропускаю какие-либо шаги, , пожалуйста, сообщите! В противном случае, я могу, вероятно, выяснить, как добавить преобразователь файловой системы из документов Ivy, но понятия не имею, как чтобы заставить publish-locally цель работать. Есть идеи? Заранее спасибо!

Ответы [ 2 ]

3 голосов
/ 16 января 2012

Я бы тоже предпочел подход Маркс.

Что касается publish-locally, вы можете указать задаче публикации, какой преобразователь (resolver="local") использовать.Таким образом он может публиковаться в локальной файловой системе или в любом определенном преобразователе.

<ivy:publish 
        resolver="local" 
        overwrite="true"
        revision="${project.version}">  
        <artifacts pattern="dist/[artifact]-[revision].[type]" />
    </ivy:publish>

И если вы используете цепной распознаватель, вы должны установить returnFirst="true", чтобы разрешение остановилось, когда что-то было найдено локально.

2 голосов
/ 15 января 2012

Ivy поддерживает динамические версии:

Стабильный код будет ссылаться на последнюю утвержденную версию jar:

<dependency org="my-org" name="commons" rev="latest.release"/>

Нестабильный (в разработке) код будет ссылаться на последнюю неутвержденную версиюcode

<dependency org="my-org" name="commons" rev="latest.integration"/>

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

(См. Атрибут состояния в ivy publish task)

Примечание: В Maven у вас есть два типа репозитория, релиз и снимок.Поддержка плющом этой концепции более тонкая и мощная ИМХО.

...