Если вы часто используете maven, то наверняка сталкивались с ситуацией когда какого-нибудь нужного артефакта не оказывается в maven central. Конечно всегда можно установить недостающий джарник в ваш локальный репозиторий
~/.m2
, но это отрицательно сказывается на переносимости билда, ведь на машине коллеги, у которого данный jar не установлен, билд уже не соберется.
Так же есть возможность использовать в качестве зависимости локальный файл не из репозитория, но для этого в проекте его опять же необходимо где-то хранить, а пушить либы в source control не очень хорошо.
Но существет еще один вариант. Вы можите использовать один из своих репозиториев на Google Code или GitHub в качестве хранилища maven артефактов. Рассмотрим как это можно сделать
Я покажу на примере GitHub’a, но никакой принципиальной разницы нету, можно использвоать хоть BitBucket, хоть Google Code. Главное чтобы у вас был доступ по HTTP(S) к корню вашего репозитория.
В качестве примера я положу в репозиторий платформы и инструменты из Android SDK, т.к. новые версии платформы в maven central появляются с огромным отставанием, если появляются вообще. Для упрощения деплоймента Android SDK будем использовать замечательный проект maven-android-sdk-deployer.
Идем на GitHub и создаем новый репозиторий, назовем его maven-repo, к примеру. Делаем git clone, переходим в папку нашей рабочей копии и создаем две папки releases и snapshots.
Устанавливаем Android SDK, закачиваем необходимые платформы и дополнения и создаем переменную окружения ANDROID_HOME
, указывающую на SDK.
Клонируем maven-android-sdk-deployer. Для установки компанентов платформы в ваш локальный ~/.m2
достаточно выполнить mvn install, но нам нужно установить артефакты в наш локальный репозиторий. Для этого необходимо немного подредактировать корневой pom.xml. Открываем его, находим проперти repo.url и проставляем ему URL, указывающий на рабочию копию нашего репозитория. URL на точку в файловой системе должен начинаться с префикса file://
и, например, у меня выглядит так:
file:///Users/TheDimasig/Dropbox/sources/my/maven-repo/releases
Все готово чтобы задеплоить артефакты локально. Делаем mvn deploy, откидываемся на спинку табуретки и наслаждаемся процессом 🙂 Внимание, на момент написания статьи maven-android-sdk-deployer, содержал багу. Дело в том, что Google решил убрать из SDK Manager’а джарник аналитики, поэтому чтобы процесс не падал с ошибкой на шаге деплоя аналитики, необходимо закомментировать модуль analytics внутри maven-android-sdk-deployer/extras/pom.xml
Почти все готово. Переходим в папку нашего репозитория и делаем
git add . git commit -m 'Android SDK artifacts' git push
Репозиторий проинициализирован и готов к использованию! Открываем maven проект, которому необходимы зависимости из него и добавляем URL репозитория в pom.xml
<repositories> <repository> <id>d-tarasov-releases</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/releases</url> </repository> </repositories>
Вот и все. Теперь в зависимостях проекта можно указывать артефакты из нашего репозитория.
Кроме этого можно настроить деплой наших maven проектов в только что созданный репозиторий. Для этого в pom.xml необходимо добавить секцию distributionManagement.
<distributionManagement> <repository> <id>repo</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/releases</url> </repository> <snapshotRepository> <id>snapshot-repo</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/snapshots</url> </snapshotRepository> </distributionManagement>
Но если непосредсвтенно сделать mvn deploy то билд завершится с ошибкой, т.к. maven попытается задеплоить артефакты не в вашу локальную рабочую копию репозитория артефактов, а непосредственно на гитхаб. Чтобы этого избежать необходимо вызвать deploy с параметром altDeploymentRepository
mvn -DaltDeploymentRepository=snapshot-repo::default::file:///Users/TheDimasig/Dropbox/sources/my/maven-repo/snapshots clean deploy
После этого можно как обычно делать git add, commit и пушить ваш артефакт уже на гитхаб.
Большим минусом является то, что GitHub имеет ограничение на максимальный размер бинарного файла доступного по http. Из за этого некоторые артефакты не могут быть использованы, так как при обращении к ним по http, выдается ошибка
Error: blob is too big
ссылка на оригинал статьи http://habrahabr.ru/post/170815/
Добавить комментарий