Комментарии 7
Вы знаете, есть и еще один вариант. Вместо менеджера репозиториев может быть сам репозиторий. Если вы поставляете продукт, репозиторий в виде папок с файлами вполне может иметь место. Главное — научиться его автоматически собирать. В таком виде поставляется например Apache Karaf.
Если вам нужны воспроизводимые сборки
Ну и так, мелкое замечание — не всегда это тоже хорошо. Скажем, у вас в зависимостях была некая уязвимая для атаки штуковина (широко известен пример с commons collections). Если через много лет кто-то решит собрать ваш проект, далеко не очевидно, что нужно воспроизводить вашу уязвимую для атаки сборку. Может быть лучше упасть. Но я боюсь, что это уже за пределами возможностей отдельно взятого мавена.
Если вы поставляете продукт, репозиторий в виде папок с файлами вполне может иметь место.
Вместе с исходниками поставлять ещё репозиторий, в котором лежат собранные джарки?
Где вы видите слово исходники? Я говорю про собранный продукт, типа условной Вебсферы. В котором обычно куча jar-ов, лежащих иногда там и тут в папках lib. Вот вместо них я бы поставлял репозиторий, по структуре соответствующий maven local.
Блог пост на сайте компании, фаундеры которой это безобразие и придумали — это, конечно, прекрасно. Но, как говорится, слишком мало, и слишком поздно. Дебильная система Мавена прямо таки толкает вас прописывать репозитории в pom.xml
. Например, как вообще можно поменять settings.xml
на облачном сервере CI, где у вас не доступа к инфраструктуре?
Вот вам 2 полезных добавления к статье (@poxvuibr можешь их дописать как P.S. если хочешь):
Пользуйтесь вычищением репозиториев из pom.xml в Artifactory. Если кто-то в команде таки поленился сделать правильно, и наговнякал, билд на CI упадёт, так как из
pom.xml
будут удалены репозитории.
- По крайней мере на CI сервере (а лучше везде) пользуйтесь Maven Wrapper-ом. В файле
maven-wrapper.properties
вы можете прописатьdistributionUrl
к произвольному дистрибутиву Мавена и это дает вам возможность скачивать из Artifactory дистибутив, в котором уже будет лежать правильныйsettings.xml
с правильными репозиториями и использовать только его. Никто не запретит, опять же, разработчикам поставить Мавен из коробки и нафигачить любых репозиториев вsettings.xml
иpom.xml
, но если ваш CI пользуется wrapper-ом, который скачивает дистрибутив с правильными репозиториями, ваша сборка будет проходить правильно, и падать, если что не так.
Да, репозитории в помах это еще та чехарда — при большом количестве проектов и длинной истории могут создавать вполне реальные проблемы. Я для себя со временем пришел к такому решению — на рабочий комп ставится sonatype nexus (maven repository), a settings.xml содержит единственную запись:
<mirrors>
<mirror>
<!--This sends everything else to /public -->
<id>lnexus</id>
<mirrorOf>*</mirrorOf>
<url>http://localhost:8081/repository/public</url>
</mirror>
</mirrors>
Сначала о недостатках — репозиторий отбирает часть ресурсов у компа, особенно место на диске. Но это достаточно просто нивелируется железом. Достаточно сказать, что я полгода не замечал фоновый WebSphere Full Profile + Liferay + Application (забыл выключить после смены проекта), чтобы понять, что этот недостаток не так существеннен.
Теперь о достоинствах:
- весь роутинг — мои репозитории + OSS репозитории + проектовые репозитории управляются через nexus (Web UI), что гораздо удобнее чем руками в XML
- мне не надо теперь иметь несколько settings.xml (для работы и для себя). Nexus автоматически отслеживает доступность репозиториев и автоматически их подключает.
- оптимизация трафика — Nexus "умнее" общается с удалёнными репозиториями
- локальный репозиторий (не nexus) со временем забивается мусором, но в моём случае это не важно — я легко могу его стереть — всё нужное моментально восстановится из nexus
Почему repository в pom.xml — плохая идея