Подтвердить что ты не робот

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

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

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

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

UPDATE2: я встретил эту техническую документацию соната, в которой представлены различные этапы усыновления/зрелости, каждый с разными целями использования для менеджера хранилища Maven.

4b9b3361

ОТВЕТЫ

Ответ 1

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

  • Внутренний выпуск
  • Внутренний снимок
  • Внутренняя сторонняя сторона для кода, используемого в доме, который поступает из внешних источников или для одобренных сторонних версий. Поместите JDBC-драйверы, javax. * Вещи и прочее от клиентов и партнеров здесь.
  • Внешние прокси общий прокси для всех обычных источников, таких как m2, codehaus и т.д.

Настройте Nexus, чтобы сделать следующее для внутренних репозиториев

  • Удаление старых снимков с регулярными интервалами
  • Удалить снимки при выпуске
  • Создайте индексные файлы. Это ускоряет локальные сборки.

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

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

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

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

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

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

Ответ 2

Определенно используйте Nexus.: P

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

Говоря об этом, Artifactory является достойным и работоспособным.

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 7

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

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

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

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