Добрый день!

Про утилиту сборки для Java-проектов Maven и про возможность создания локального сервера для Maven-репозитория с помощью Sonatype Nexus на Хабре уже упоминали (тут и тут). Однако, никакого рецепта по этому поводу представлено не было. Это неудивительно при наличии достаточно полной грамотной документации. По долгу службы мне пришлось настраивать его на нашей фирме, и оказалось, что советы из официальной документации не совсем подходят. Возникшей проблемой и способом ее решения я и хочу поделиться с сообществом. Но обо всем по порядку.

Зачем это нужно?

Локальный сервер для Maven-репозитория (как, например, Sonatype Nexus) может быть использован для хранения локальных артефактов Maven, и действительно пригодится командам, которые разрабатывают модульные приложения, но не собираются публиковать модули в общий доступ.

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

Есть три самых популярных таких сервера:

Sonatype Nexus
Apache Archiva
Artifactory

По отзывам Nexus — самый функциональный и удобный. Минус его — в том, что некоторые фичи доступны только в платной версии, но для наших целей и бесплатных хватало с головой. Вобщем, мой выбор остановился на нем. Других я даже не попробовал.

Установка Sonatype Nexus

На данном этапе можно смело следовать документации, на моей памяти проблем не возникало. На сайте Sonatype есть неплохой обучающий скринкаст. Вкратце перескажу суть процесса установки.

Есть 2 способа развернуть Nexus:

как WAR-файл на любом контейнере(например, Apache Tomcat)
распаковать архив и запустить вручную(внутри используется Jetty). Порт по умолчанию — 8081. URL: http://host:8081/nexus

По умолчанию, логин / пароль — admin / admin123.

В принципе, им уже можно пользоваться без всякой настройки(из коробки доступны прокси-репозитории Maven central, Codehaus, Apache), но имеет смысл настроить права доступа, группы репозиториев, добавить необходимые прокси-репозитории, включить индексирование, и.т.п.

Настройка Maven для использования Sonatype Nexus в качестве прокси

Данный этап уже гораздо неоднозначнее. Посмотрим, что предлагает нам официальная документация.

Здесь рекомендуют в settings.xml записать следующее:

<mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://host:8081/nexus/content/groups/public</url> </mirror> * This source code was highlighted with Source Code Highlighter.

При этом, там честно говорят, что такая настройка может вызвать проблемы в случае, если для проекта в pom.xml определены сторонние репозитории с помощью тега <repositories>. Дело в том, что при такой настройке Maven опрашивает только Nexus, который может быть не осведомлен о наличии дополнительных репозиториев. Так уж получилось, что в нашем проект такие репозитории имеются. Документация советует в таких ситуациях добавлять все такие репозитории в public группу локального репозитория.

Вполне логичный совет, но имеется ряд организационных проблем, связанных с ограничением доступа к администрированию Nexus. Так, например, для того чтобы попробовать в деле какую-нибудь библиотеку стороннюю, разработчик вынужден дергать админа, чтоб тот добавил соответствующий репозиторий в Nexus. На время отключать это зеркало в settings.xml — тот еще костыль.

Какие еще можно использовать варианты для преодоления описанной проблемы? На ум приходят следующие 3:

Использовать зеркало с параметром <mirrorOf>central</mirrorOf&gt.
Все работает, но выгоды в производительности и в экономии трафика от использования зеркала мало. В этом случае Nexus будет проксировать только главный репозиторий, так как все дополнительные репозитории опрашиваются раньше, чем central.
Добавлять Nexus как репозиторий в каждый проект в pom.xml. Этот вариант еще менее удобен, кроме того не подходит, например, для чужих и публичных проектов (когда нельзя вносить изменения в pom.xml). Зато опрос Nexus_a можно сделать первым в очереди.
Добавить Nexus как репозиторий в профиль по умолчанию. Это подход, объединяющий положительные черты вышепредставленых — централизованная настройка и эффективное проксирование

Рассмотрим подробнее третий вариант. Он сводится к написанию в settings.xml следующего кода:

<profiles> <profile> <id>nexus</id> <repositories> <repository> <id>nexus-repo</id> <name>Nexus repo</name> <url>http://host:8081/nexus/content/groups/public</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>nexus-repo</id> <name>Nexus repo </name> <url>http://host:8081/nexus/content/groups/public</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>nexus</activeProfile> </activeProfiles> * This source code was highlighted with Source Code Highlighter.

По сути, данной настройкой мы добавляем профиль, активный по умолчанию, который добавляет Nexus как обычный репозиторий. И добавляется он первым в очередь.

Теперь все запросы сначала отправляются Nexus_у. Тот в зависимости от наличия запрашиваемого артефакта в хранимых и подключенных прокси-репозиториях либо отдает запрошенный артефакт, либо отвечает отрицательно. В случае отрицательного ответа Maven просто продолжит опрос перечисленных в pom.xml репозиториев, а затем обратится и к репозиторию Maven central.

Примущества подхода

настраивается в одном месте, один раз для всех проектов;
ускорение доступа к артефактам из всех репозиториев, зарегистрированных в Nexus (в том числе для дополнительных репозиториев);
не нарушается работоспособность сборки в случае, если внешний репозиторий, описанный в pom.xml, не зерегистрирован в Nexus;
возможность временного отключения использования Nexus (mvn -P !nexus).

При этом настройку зеркала нужно убрать вообще, и не ставить даже на central, потому что это исключит последнее преимущество(временное отключение). Разумеется, можно держать несколько файлов setting.xml и подменять их (mvn -s filepath), но мне это не кажется элегантным решением.

Недостатки подхода

Выявлен только один недостаток — существует опасность забыть добавить необходимый дополнительный репозиторий в pom.xml. Правда, следует отметить, что этот недостаток касается фактически всех подходов (кроме 2-го) а также может проявляться вообще в отсутствие локального Nexus репозитория.

Дело в том, что если сторонний репозиторий добавлен в Nexus, то у разработчиков, у которых Nexus подключен, сборка будет проходить без проблем. Но разработчики, без настроенного Nexus не смогут собрать проект вообще, так как их Maven не будет знать, из какого дополнительного репозитория нужно запросить артефакты.

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

Послесловие

Надо сказать, что совет авторов документации добавлять все дополнительные репозитории, описанные в pom.xml проектов, в Nexus никто не отменял. Это действительно лучше делать для того, чтобы получить выгоду от использования проксирующего Maven-репозитория. Но зато применение предложенного решения делает это необязательным, что может убрать время ожидания разработчика, пока админ добавит нужный репозиторий.

UPD: Наткнулся на интересную статью, в которой рассматриваются похожие вопросы.

Настройка репозитория Sonatype Nexus для проксирования артефактов Maven