Apache Ivy: куда мне положить все эти банки? - PullRequest
Новая
       17

Apache Ivy: куда мне положить все эти банки?

1 голос
/ 09 сентября 2011

Я пытаюсь убедить старших на своем рабочем месте перейти на Apache Ivy. Мне удалось заставить несколько проектов-песочниц работать с использованием Ivy для построения сборки, и теперь у меня есть возможность собрать предложение по миграции.

Мы все согласны в одном: мы не хотим доверять JAR-файлам, которые находятся в общедоступных каталогах! Я знаю, я немного параноик, да. Но нам бы хотелось иметь установку, в которой мы извлекаем JAR из надежного источника (либо загружаем его из самого проекта с открытым исходным кодом, либо, скорее всего, из gulp, публичного репо), и используем его в течение некоторого времени, прежде чем мы " сертифицируйте"это (дайте ему наше благословение как безопасный артефакт для использования).

Затем мы хотим создать общий репозиторий для всех JAR-файлов, используемых в наших многочисленных проектах.

Первоначально я думал поместить этот репозиторий в систему контроля версий (у нас есть сервер SVN). Но я не был уверен, что диктуют лучшие практики. Возможно, имеет смысл поместить наши JAR-файлы на файловый сервер и подключить к ним FTP в сценарии Ivy.

В любом случае, SVN (HTTPS) или FTP, все наши серверы проходят проверку подлинности. Итак, небольшое количество вопросов:

  1. Где мы должны публиковать все наши "сертифицированные" JAR-файлы (от `log4j` до любых собственных JAR-файлов, которые мы производим)? Что диктуют лучшие практики?
  2. Тип резолвера "ivyrep" не принимает атрибуты имени пользователя или пароля. Если наш «JAR-сервер» (FTP, SVN и т. Д.) Аутентифицирован, как мне настроить сценарии Ivy для входа?

Ответы [ 2 ]

2 голосов
/ 11 сентября 2011

Я должен повторить рекомендацию Брайана использовать менеджер репозитория, такой как Nexus . Это намного меньше работы в долгосрочной перспективе. Вы также обнаружите, что профессиональная версия Nexus позволяет создавать процессы утверждения вокруг репозиториев, которые вы планируете использовать в своей сборке. См. Функциональность Комплект поставки .

Если, с другой стороны, вы решили создать свой собственный репозиторий, то у Айви есть инструменты для этой работы. Вам нужно очень хорошо ознакомиться с файлом ivy settings и с тем, как он объявляет и использует resolvers .

Если репозиторий доступен через HTTPS, распознаватель url должен иметь к нему доступ. Преобразователь будет предполагать, что каждая версия артефакта находится в отдельном каталоге, и вам нужно будет указать шаблон URL, который ivy будет использовать при доступе к хранилищу: 

<url name="two-patterns-example">
  <ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
  <artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>

Шаблон полностью гибок в том, как вы храните артефакты.

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

Наконец, протокол FTP также поддерживается. Его трудно найти в документе, но он поддерживается распознавателем vfs .

Я думаю, что достаточно информации о параметре, который я не рекомендую :-) Сказав, что однажды я создал хранилище на основе FTP для управления выпусками для клиентов. Полезно иметь такой мощный инструмент: -)

1 голос
/ 09 сентября 2011

Почему бы не использовать что-то вроде Sonatype Nexus .Я видел, как он использовался для Maven, и я верю, что он будет работать для Ivy.

Вы можете настроить его для загрузки из удаленных репозиториев в (скажем) «тестовый» репозиторий.Затем вы можете оценить эти файлы .jars и, если они хороши, загрузить их в «одобренный» репозиторий для общего потребления.Вокруг этого есть некоторая аутентификация, но вам придется оценить ее более подробно.Конечно, вы можете ограничить загрузку в репозитории с помощью пары имя пользователя / пароль.

...