Если вы часто используете 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