Записки программиста

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

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

Вот некоторые юзкейсы, которые приходят на ум:

• Самое очевидное. У вас есть артефакты, которые хотелось бы шарить между командами и/или проектами, но эти артефакты не хочется выкладывать в открытый доступ;
• Nexus можно поднять в локальной сети и настроить в качестве прокси для Maven Central. За счет этого не приходится «скачивать интернет», когда, например, в команду приходит новый человек или кто-то меняет компьютер. Все артефакты быстро сливаются из кэша в локалке;
• Представьте, что у вашего провайдера что-то сломалось и вы сидите без интернета. В этом случае работа не встанет из-за недоступности артефактов, так как в локальной сети есть кэшик;
• Допустим, что артефакт, от которого вы зависите, по каким-то причинам вдруг исчезнет из публичного репозитория. Ходят слухи, что иногда такое случается. Возможно, это будет не артефакт целиком, а только определенная его версия, неважно. Тогда вы сможете залить закэшированный в вашей файловой системе артефакт в локальный Nexus и продолжать работать, как ни в чем не бывало;
• Некоторые артефакты бывают не залиты в Maven Central. Например, они могут просто лежать в виде исходников на каком-нибудь BitBucket. Опять таки, возможно, это не весь артефакт, а какая-то его development версия с очень важными для вас изменениями. Не нужно копировать исходники к себе в проект и пересобирать их после каждого clean. Или, затаив дыхание, ждать релиза. Просто соберите артефакт и залейте в Nexus;
• Есть еще много вариаций на тему предыдущего случая. Например, библиотека может быть заброшена. Еще ее автор может очень долго рассматривать ваш pull request или вовсе отклонить его. Создаем форк, собираем, заливаем в Nexus;
• Вообще, неплохой идеей является распиливание крупных проектов на маленькие артефакты и хранение их в Nexus. Как минимум, это может существенно ускорить сборку проекта. Кроме того, можно повторно использовать некоторые компоненты в разных системах. При этом может получиться, например, что Android-разработчик фактически пишет кусочек бэкенда, когда он коммитит в проект, который используется как на бэкенде, так и в мобильном приложении;
• Вы хотите сделать некоторые артефакты общедоступными, но Maven Central по каким-то причинам не подходит. Возможно, ваши артефакты не принимают туда из-за лицензии. Или у вас очень много артефактов, а также большая команда разработчиков, которые, вообще говоря, могут приходить в компанию и уходить из нее. В таких случаях может иметь смысл поднять self hosted менеджер репозиториев;

Как по мне, причин более, чем достаточно, для того, чтобы держать Nexus в любой компании, где пишут под JVM. Даже если он будем пустым. Типа, про запас. Чтобы был, если вдруг понадобится. Ради экономии ресурсов Nexus можно поселить на билд сервер рядом с Jenkins.

Установка и базовая настройка

Все описанные ниже шаги были проверены в Ubuntu Linux 14.04 LTS, но, по идее, будут верны и для других версий Ubuntu, а также мало отличаться для других дистрибутивов Linux.

Готового deb-пакета с Nexus нет, но, к счастью, руками он устанавливается не сложно. На машине должна быть установлена виртуальная машина Java. Не так давно, в заметке, посвященной Cassandra, мы выясняли, как она ставится:

Далее качаем архив с Nexus и распаковываем его в /usr/local:

С этого места — под root’ом:

Заводим нового пользователя и делаем его владельцем распакованных файлов:

Делаем так, чтобы Nexus запускался при старте системы:

В файле /etc/init.d/nexus кое-что нужно поправить:

Теперь уже под обычным пользователем:

В браузере открываем http://nexus.example.ru:8081/nexus/ — здесь и далее предполагается, что машина называется nexus.example.ru. Справа вверху жмем Log in, вводим логин admin и пароль admin123. После входа справа вверху открываем Profile, меняем пароль. В Security → Users отключаем всех лишних пользователей, меняем email у админа. Там же можно завести пользователей с нужными правами, это не сложно.

Далее переходим к списку репозиториев:

Создаем новый hosted репозиторий, поля заполняем как-то так:

На этом настройку будем считать завершенной. При желании совсем несложно ограничить доступ к Nexus, воспользовавшись iptables, или поднять рядом Nginx с шифрованием трафика. Но эти вопросы мы ранее уже рассматривали, поэтому перейдем непосредственно к работе с репозиториями.

Сборка артефакта и его заливка вручную

Создаем новый Scala-проект, как мы это уже много раз делали, пишем код в таком стиле:

Говорим:

В итоге получим файл target/scala-2.11/test-package_2.11-0.1.jar или вроде того. Заливаем артефакт в Nexus в последний созданный репозиторий через вкладку Artifact Upload. Указываем Group, Artifact, Version.

Заводим еще один проект, в коде пишем:

В файл build.sbt дописываем:

Собираем, проверяем, что все работает.

Еще есть команды sbt package-doc и sbt package-src. Как можно без труда догадаться, они собирают jar’ники с документацией и исходниками.

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

Использование Nexus как прокси

Чтобы все артефакты качались через Nexus, создаем файл ~/.sbt/repositories такого содержания:

Приведенная выше ссылка не уместилась по ширине, но вы можете скопировать ее в списке репозиториев. Это репозиторий с именем Central.

Далее создаем ~/.sbt/0.13/plugins/nexus-example-ru.sbt:

Можете взять какой-нибудь из своих проектов, посмотреть на его зависимости, удалить пару соответствующих артефактов в каталоге ~/.ivy2/cache/ и затем сказать sbt compile. Если все было сделано правильно, вы увидите, что теперь артефакты тянутся через nexus.example.ru.

Автоматическая заливка

Возвращаемся к проекту test-package. Файл build.sbt редактируем как-то так:

Если вы хотите заливать -SNAPSHOT и релизные версии артефакта в разные репозитории, тут написано, как это настроить.

Все credentials мы уже настроили на шаге про использование Nexus в роли прокси. Поэтому просто говорим sbt publish. Будет залит обычный jar’ник, а также javadoc и sources.

Во втором проекте, который зависит от test-package, изменяем build.sbt:

Обратите внимание, что теперь используется два знака процента, а не один. То есть, при заливке sbt автоматически указал имя артефакта test-package_2.11, как, собственно, и принято в мире Scala. Проверяем, что все собирается.

Также SBT поддерживает кросс-сборку. То есть, в одном проекте можно собирать артефакт для нескольких версий языка Scala. Например, чтобы артефакт собирался для Scala 2.10 и 2.11, в build.sbt нужно дописать:

Тестирование, сборка и публикация всех версий артефакта:

Бывает так, что нужно использовать немного разные версии библиотек или флаги компилятора в зависимости от версии Scala. Это делается примерно так:

Нужно отметить, что перед sbt publish не лишним будет делать sbt publish-local для «заливки» артефакта в кэш, протестировать, что все ОК, и только потом заливать артефакт в репозиторий.

Заключение

Немного ссылок по теме:

• Страница проекта на сайте Sonatype;
• Исходники бесплатной версии Nexus на GitHub;
• Официальная документация, есть вариант в PDF;
• Гайд про заливку в Maven Central на английском языке;
• Гайд про заливку в Maven Central на русском языке;
• Альтернативы Nexus — Artifactory от JFrog и Apache Archiva;
• Сравнение возможностей разных менеджеров репозиториев;

А куда вы заливаете артефакты?

Метки: Linux, Scala, Разработка, Функциональное программирование.