Советы по ведению внутреннего репозитория Maven?

Question

Я заинтересован в поддержке Maven 2 репозитория для моей организации. Каковы некоторые из указателей и ловушек, которые могли бы помочь.

Каким руководствам пользователи должны следовать при настройке стандартов для загрузки или публикации собственных артефактов в хранилище при выпуске своего кода? Какие виды управления / правила у вас есть для этого типа вещей? Что вы включаете в руководство / документацию разработчика?

ОБНОВЛЕНИЕ : Мы поддержали Nexus и были очень довольны им - следовали большинству указаний Сэла и не имели никаких проблем. Кроме того, мы ограничили доступ к развертыванию и автоматическую сборку / развертывание артефактов моментальных снимков через сервер Hudson CI. Hudson может проанализировать все зависимости проекта в восходящем / нисходящем направлении, поэтому если из-за проблемы компиляции, сбоя теста или другого нарушения сборка будет прервана, развертывание не произойдет. Будьте осторожны с развертыванием моментальных снимков в Maven2 / Maven3, так как метаданные изменились между двумя версиями. Стратегия развертывания моментальных снимков «Только для Гудзона» поможет смягчить это. Мы не используем плагин Release, но несколько раз описали плагин Versions , когда собираемся переместить снимок в релиз. Мы также используем m2eclipse, и он, похоже, очень хорошо работает с Nexus, поскольку из файла настроек он может видеть Nexus и знает, как индексировать информацию об артефактах для поиска оттуда. (Хотя мне пришлось настроить некоторые из этих параметров, чтобы они полностью индексировали наши внутренние снимки.) Я также рекомендую развернуть исходный файл jar со своими артефактами в качестве стандартной практики, если вы заинтересованы в этом. Мы настраиваем это в супер POM.

ОБНОВЛЕНИЕ2 : я встречал этот документ Sonatype , в котором подробно описываются различные этапы принятия / зрелости, каждый из которых имеет разные цели использования для менеджера репозитория Maven.

Answer 1

Я бы порекомендовал установить один сервер Nexus с как минимум четырьмя репозиториями. Я бы не рекомендовал артефакт. Бесплатная версия Nexus отлично подходит для разработчиков менее 20 в менее чем трех группах. Если у вас больше пользователей, чем это, сделайте себе одолжение и заплатите за выпуск Sonatype. Интеграция с LDAP окупается.

1. Внутренний выпуск
2. Внутренний снимок
3. Внутренняя третья сторона для кода, используемого в доме, который поступает из внешних источников, или для утвержденных сторонних версий. Разместите здесь драйверы JDBC, javax. * И прочее от клиентов и партнеров.
4. Внешние прокси общий прокси для всех обычных источников, таких как m2, codehaus и т. Д.

Настройка Nexus для выполнения следующих операций для внутренних репозиториев

1. Удаление старых снимков через равные промежутки времени
2. Удаление снимков при выпуске
3. Создание индексных файлов. Это также ускоряет локальные сборки

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

Предоставьте общий прокси для ваших клиентов. В Nexus вы можете добавить несколько прокси к общим источникам Maven (Apache, JBoss, Codehaus) и иметь один прокси, доступный для внутренних клиентов. Это значительно упрощает добавление и удаление источников из ваших клиентов.

Не смешивайте внутренние и сторонние артефакты в одном и том же хранилище. Nexus позволяет добавлять файлы JAR во внутренний репозиторий через веб-интерфейс. Я рекомендую это как способ добавления ваших драйверов JDBC и другого внешнего кода третьим лицам. Пользовательский интерфейс довольно удобен в использовании по сравнению с большинством корпоративных программ .

Определите общий родительский POM , который определяет внутренний снимок и выпускает репозитории с помощью тега distributionManagement . Я знаю, что многие люди говорят вам не делать этого. И хотя я свободно признаю, что с этим возникают всевозможные проблемы, все будет хорошо, если клиенты будут создавать только выпуски и снимки для развертывания в одном внутреннем репозитории.

Если у вас есть существующее неправильно управляемое хранилище Maven , создайте 5-е хранилище под названием Legacy и поместите туда все хранилища. Установите задачу cron для удаления старых файлов из старых, когда им исполнился год. Это дает всем год, чтобы уйти от этого и обновить свои poms.

Создание простого соглашения о присвоении имен для внутренних артефактов. Я предпочитаю GroupID Department.Function.Project и ArtifactId для этого componentName . Для внутренних репозиториев, com / org / net и название компании, скорее всего, не будут иметь значения. И неправильно, если компания меняет название. Гораздо менее вероятно, что отдел продаж, бухгалтерии или инвентаря будет переименован.

Answer 2

Обязательно используйте Nexus . : P

Я использовал и Nexus, и Artifactory. Интерфейс для Nexus намного более надёжный, намного более настраиваемый и, конечно, написанный Sonatype , который хорошо отражает все, что хорошо Maven.

При этом, Artifactory достойный и работоспособный.

• Обзор Nexus vs. Artifactory
• Боже мой! Конечно, вот SO вопрос по этому вопросу.
• Sonatype сравнивает функции
• jFrog (создатель Artifactory) делает сравнение характеристик

Answer 3

Я использую Artifactory сам, и мне нравится пользовательский интерфейс и простота развертывания / обслуживания. Тем не менее, я никогда не использовал Nexus и не могу помочь вам в правильном сравнении функций.

Вот некоторые вещи, которые мне очень нравятся в Artifactory (имейте в виду, что у Nexus тоже могут быть эти функции):

1. Хороший интерфейс Web 2.0.
2. Возможность импортировать ваш локальный репозиторий Maven, чтобы помочь вам начать работу.
3. Простота интеграции с существующими серверами LDAP для обеспечения безопасности (я большой поклонник единого хранилища для хранения учетных данных).

Учитывая, что на самом деле есть только две основные реализации репозитория Maven, если вы действительно хотите убедиться, что сделали правильный выбор, я бы рекомендовал попробовать оба варианта и решить для себя, какой вам больше нравится.

Answer 4

Использование Артефактория .

Answer 5

В качестве ОРИГИНАЛЬНОГО ВОПРОСА (технические проблемы, которые следует учитывать при создании хранилища M2), я бы порекомендовал создать пользователя только для чтения для просмотра хранилища и администратора для каждого администратора (который сказал: один доступ для чтения). единственный пользователь для всех тех пользователей, которые не являются администраторами). Более того, я бы рекомендовал периодически создавать резервные образы (возможно, один раз в день?). Очень важно, если ваш репозиторий большой или вы время от времени устанавливаете собственные артефакты.

И последнее, но не менее важное: при добавлении новых удаленных репозиториев вы должны добавить фильтры включения / исключения, чтобы поиск артефактов в репозитории выполнялся быстрее.

Есть много других вопросов, которые необходимо рассмотреть, но это основные проблемы, с которыми я столкнулся при управлении внутренним хранилищем Maven.

Для записи я использую Nexus и Artifactory; Я могу четко заявить, что, хотя Nexus очень прост и работает (хотя у меня иногда возникают проблемы с процессом установки в Ubuntu), его бесплатная версия не может конкурировать с бесплатной редакцией сообщества Artifactory. Исключая удивительный веб-интерфейс Artifactory Web 2, его основные функции, такие как управление безопасностью, периодическое резервное копирование и проблемы доступности, намного превосходят возможности Nexus.

Answer 6

Что еще нужно учитывать:

http://archiva.apache.org/

Answer 7

Возможно, это очевидно, но для воспроизводимости разработчики никогда не должны перезаписывать артефакты, они должны быть новыми версиями.

Это также относится к вышестоящим репозиториям. Если вы загружаете Apache-commons версии 1.2.3, вам никогда не следует загружать его снова. Исправления приходят из последних версий, не применяются к существующим версиям.