Comments 55
Есть менеджеры репозиториев, например nexus и artifactory. У них есть полноценные бесплатные версии, которые (конкретно могу утверждать про nexus, но не думаю что с другими все сильно отличается) устанавливаются и запускаются максимум за полчаса. Есть например готовые docker images, откуда можно запустить вообще без усилий, если у вас есть docker.
И дальше свой nexus надо прописать раз и навсегда в settings.xml, и с ним работать. Если вы не кустарь одиночка с мотором (с), это будет одно из правильных решений. А если вы работаете в команде — то пожалуй и единственно правильное.
Установить и запустить. И дальше все проблемы будут решаться через UI — задеплоить артефакт, которого нет в репозиториях, подключить еще один репозиторий помимо central, и прочее, и прочее.
Ну вот зачем вы учите начинающих плохому? )))
Есть менеджеры репозиториев, например nexus и artifactory.
Я тут совершенно согласен часто нужно класть библиотеки именно туда. В статье об этом есть ремарка :)
И дальше свой nexus надо прописать раз и навсегда в settings.xml, и с ним работать.
А вот тут я считаю, что настройки надо по возможности воткнуть в pom.xml и завернуть в maven профиль, чтобы не было необходимости что-то настраивать в settings.xml
Если вы не кустарь одиночка с мотором (с), это будет одно из правильных решений. А если вы работаете в команде — то пожалуй и единственно правильное.
А если вы в команде — тем более класть в профиль, чтобы не заниматься правкой settings.xml на регулярной основе
Установить и запустить. И дальше все проблемы будут решаться через UI — задеплоить артефакт, которого нет в репозиториях, подключить еще один репозиторий помимо central, и прочее, и прочее.
Это, повторюсь, хороший вариант. В статье я хотел сделать фокус именно на работе с maven. Этот вариант работы, на мой взгляд, описан в пункте про подключение удалённого репозитория.
Собственно, я имел в виду, что ваши варианты — они конечно да, самые базовые, но в реальности все-таки намного проще настроить репозиторий. В случае компании, которая живет в интранете — это просто must have, без вариантов вообще. И на это стоило бы напирать сильнее.
Я не совсем согласен с такой точкой зрения. Иметь свой корпоративный репозиторий в команде это, конечно же, хорошо и правильно. Но я всегда следую принципу, что проект должен уметь собираться всегда и везде, без лишних геморроев. Локальный репозиторий проекта — разумное решение, когда тебе нужен всего лишь какой-нибудь пропиетарный драйвер. Это делает сборку проекта автономной и независимой от окружения. Maven Wrapper при этом еще отлично помогает.
Но с другой стороны, для maven же есть средства, которые умеют копировать репозитории целиком. Так что если у вас зависимости лежат скажем на github в виде локального репозитория, перетащить их в nexus будет совсем просто.
Это делает сборку проекта автономной и независимой от окружения. Maven Wrapper при этом еще отлично помогает.
Именно это я и имел в виду. А Maven Wrapper — вещь! Я когда gradlew увидел — долго горевал, что для maven такого нет. Пока через час не выяснил, что вполне себе есть!
Спасибо, дорогой за луч света в этом плотном слое говна. Я тут обфейспалмился до крови, читая этот ад (я про статью, конечно). У Artifactory тоже есть бесплатный оpensource, конечно. У нас есть генератор settings.xml, который вообще делает всё за тебя: https://www.youtube.com/watch?v=MGXrPz9wwOY
Кроме того, у нас есть еще и Maven plugin, который добавляет metadata к задеплоенным артифактам.
mvn deploy:deploy-file
А потом вы ошибаетесь в -Dpackaging=pom и записываете вместо pom — jar. Поздравляю — у вас битый локальный репозиторий и теперь резолв артефакта будет идти с ошибкой.
Есть одна проблема с локальным репозиторием — для мультимодульного проекта придется корректировать путь к нему в каждом pom.xml, так как project.badedir будет у каждого модуля свой.
Есть одна проблема с локальным репозиторием — для мультимодульного проекта придется корректировать путь к нему в каждом pom.xml, так как project.badedir будет у каждого модуля свой.
Есть, да. Многомодульному проекту в maven вообще хочется посвятить отдельную публикацию — очень уж актуальная и важная тема.
Это к тому, что уже давно все собрано в смысле знаний о самом maven и его использовании
Да 15 лет и такое впечатление что он нисколько не изменился за эти 15 лет, да и просто не может меняться.
Ньютоновской физике даже больше 15, а учебники всё пишут и пишут :). Я попытался написать статью именно такой, какой хотел видеть её, когда про maven ещё ничего не знал. Написал с надеждой, что найдутся люди, которым будет удобно получить знания именно в такой форме.
maven { url 'https://jitpack.io' }
dependencies {
compile 'com.github.jehy:Tor-Onion-Proxy-Library:0.0.5'
}
И вот у вас прямо из гитхаба идёт импорт.
Во-первых это не совсем maven :). А во-вторых импорты с гитхаба штука опасная, если он конечно не твой собственный.
Во-вторых, никто не отменял форки.
Ну, тема статьи всё-таки maven. Поэтому на всякий случай перепишу ваше замечание так, чтобы оно лучше соответствовало контексту статьи.
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
<dependency>
<groupId>com.github.jehy</groupId>
<artifactId>Tor-Onion-Proxy-Library</artifactId>
<version>0.0.5</version>
</dependency>Действительно неплохой способ. Собирать библиотеки только нужно, но для многих это скорее плюс, чем минус. Жаль только завязан на проприетарную технологию с закрытым кодом. А так — вполне себе.
прописывать repository в поме — огромная ошибка. Никогда так не делайте, и никого не учите так делать. Вот вам блог пост от создателей мавена:
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
repository в pom.xml это действительно не всегда хорошо. Однако, в приведённой вами статье написано, что в случае, если продуктом является программа, которую не собираются использовать в качестве зависимости, то указание репозитория в помнике вполне безопасно. И, если вы хотите упростить сборку проекта для других разработчиков эта идея вполне заслуживает рассмотрения. Именно о таких кейсах я говорил. Спасибо за замечание, добавил уточнение в статье.
Особенно весело видеть в конечном приложении такой repository, который требует аутентификации ,)
Но, если это возможно, такую библиотеку лучше положить в проект и хранить прямо в системе контроля версий. Тогда библиотека будет доступна программе всегда и на любой машине, а шаг по копированию этой библиотеки в репозиторий можно не включать в мануал.
А вот так делать не надо!!! Есть грань между SCM и binary repository manager которую не следует путать. Свой собственный корпоративный репозитарий — правильное решение. Хранение библиотек в SCM — грязный хак!
А вот так делать не надо!!! Есть грань между SCM и binary repository manager которую не следует путать.
Вопрос в том, где эта грань. Тут как с картинками и всем таким. Если у вас их пара гигабайт, то нужно хранить отдельно. Хотя всякое бывает :). А, если пара иконок, то обычно хранят прямо в системе контроля версий. С библиотеками похожая ситуация. Если есть один проприетарный драйвер, или небольшой джарник из эпохи мамонтов с утерянными исходниками — то можно и прямо в исходники положить. А если там целая система с зависимостями, то лучше как-то по другому делать.
Свой собственный корпоративный репозитарий — правильное решение.
Особенно, если у вас есть своя собственная корпорация :). А если у вас свой проектик с парой джарников, то корпоративный репозиторий возможно и оверкилл.
Хранение библиотек в SCM — грязный хак!
Может и так, но в гите оптимизации для хранения бинарников появились не от того, что разработчикам просто нечего было делать.
А про хранение внутри SCM — я бы сказал так: хранить можно, но желательно даже в этом случае разделить репозитории. Пусть у вас будет git repo — но отдельный и только для артефактов. У них другой жизненный цикл, чем у ваших исходников, вы не будете делать такие же бранчи, релизить, и прочее и прочеее. А значит — разделить.
А если у вас свой проектик с парой джарников, то корпоративный репозиторий возможно и оверкилл.
Для проектов с открытым исходным кодом можно использовать центральный репозитарий. Тогда ваши артефакты могут указывать в зависимостях без подкладываний jar в SCM или deploy в корпоративный репозитарий. Есть nexus opensource edition и установка простая — скачал и запустил. Если же проект не open source и вам лень ставить свой менеджер репозитариев и делать бэкапы, то можете раскошелиться на подписку bintray и использовать как сервис для не общедоступного репозитария.
Может и так, но в гите оптимизации для хранения бинарников появились не от того, что разработчикам просто нечего было делать.
По мне так ответ проще — для хранения jpg/png для веб приложений, которых огромное число в github.
Если же проект не open source и вам лень ставить свой менеджер репозитариев и делать бэкапы, то можете раскошелиться на подписку bintray и использовать как сервис для не общедоступного репозитария.
Тут уже, думаю, вопрос личных предпочтений. Если вы считаете, что ради того, чтобы положить пару джарок в проект имеет смысл поставить Нексус или купить подписку на bintray, то, конечно надо так и делать. Я бы задумался об этом после того, как понял, что джарки придётся регулярно обновлять.
Да я тут уже обфейспалмился до крови.
Что же до SCM — то есть помнится возможность деплоить туда артефакты при помощи штатного механизма — т.е. mvn deploy. При этом SCM у вас играет роль хранилища, но работаете вы с ним как с репозиторием.
Я бы сказал, что такой подход — он ограниченно годится, но в тоже время совершенно ясно, что он даже не столько от бедности, сколько от лени. Ну опять же — потому что трудозатраты на установку своего репозитория они настолько маленькие, что это даже не смешно.
У меня вот в проекте (предыдущем на сегодня) был (и есть) nexus. Тому нексусу — наверное лет 6 или 10 уже. Никого из тех, кто его развертывал, уже давно в компании нет. Рядом, если что, такой же дремучий jenkins. Никто их не поддерживает — разве что время от времени чистят диск от ненужных сборок jenkins. И работают с этим добром человек 20. Вот такие они — трудозатраты, по стоимости машинки для запуска (виртуалка на два ядра и 8Гб) и диска для размещения всего добра, гигабайт на 100.
И валяется там на 99% вполне себе open source, типа commons collections, и огромная проблема со всем этим состоит в том, что никто уже не знает, какому проекту на самом деле какие завимости нужны, кто от кого зависит, какие у них версии, и прочая и прочая.
Там правда к этому еще прилагался ant, но разница в общем не очень велика, потому что главная проблема не в том, чем собирать, а в том, что где-то в lib лежит нечто, о чем мы не знаем, как его точно зовут, и какой оно версии. И если завтра кто-то заменит в SCM один jar на другой, похожий — мы долго будем думать, почему оно вдруг сломалось.
Bintray такой же бесплатный для opensource, а jcenter такой же центральный как и central, и Artifactory такой же бесплатный и опенсорцный как Нексус (только у нас генератор settings.xml и/или maven plugin еще есть).
https://www.youtube.com/watch?v=MGXrPz9wwOY
https://www.jfrog.com/confluence/display/RTF/Maven+Artifactory+Plugin
Из инструментария я отметил бы еще Apache Archiva
Что же вы делаете-то?! Tutorial в корпоративном блоге предлагает "Директорию lib надо закомитить и библиотека будет доступна проекту вообще всегда"? Я думаю следущая статья должна быть о том, как сорцы лучше пересылать по email-у.
К сожалению, эта тенденция в большинстве корпоративных блогов на хабре. Есть исключения (в особенности среди больших корпоратов типа mailru/yandex/ibm), но большинство тупо получает деньги за количество знаков, а не качество, вот и прёт индусятина в новом обличье.
Вот индусам сейчас обидно было.
@jbaruch, раз уж вы здесь, поведайте как у artifactory (open-source варианта) обстоят дела по следующим направлениям:
- внешняя authn/authz через http-заголовок (типа
REMOTE_USER) или openid connect; - как с возможностью автоматического деплоя в него из jenkins (при использовании jenkinsfile/pipeline plugin);
- как с возможностью использования webhook'ов/rest api для уведомлений о деплое артифакта?
В принципе, artifactory мне на первый взгляд приятней, чем nexus (а в третьей версии он таки местами ужасен), но когда смотрел в прошлый раз, отсутствие некоторых фич было блокером для сборки CI/CD pipeline'а на open-source варианте.
- В бесплатном есть только LDAP
- Это конечно всё есть, и через Artifactory Jenkins Plugin, и через Artifactory Maven Plugin (оба open source) и просто через mvn deploy
- Это через user plugin, который в Pro.
1. Вы когда деплоите, вы скорее всего используете http, и один из стандартных механизмов аутентификации юзера. Basic, NTLM, SSL. Чтобы использовать тут внешнюю, нужно допилить maven deploy plugin, а точнее видимо вагон. Внешняя тут зачем, чтобы использовать ее в этом месте вместо LDAP? Тогда это Artifactory Security Realm (ровно также, как у nexus впрочем). Это не очень сложно, я пробовал.
2. Проще всего mvn deploy, разумеется. Остальное дополнительные плюшки.
3. В nexus для этого есть RSS и расылка нотификаций почтой. Как вы хотите получать уведомления, если это асинхронный процесс? Чей это должен быть REST? Jenkins, чтобы он собрал другой зависимый артефакт?
Не то чтобы очень странного ,)
- Я не против использования http authn для деплоя (из jenkins'а или из maven/gradle/sbt — не важно), но для работы с самим artifactory/nexus хочется иметь поменьше геморроя, в частности SSO. OIDC в этом плане является стандартом наравне с более сложным и неприятным SAML, который мне сильно избыточен. И сервер авторизации, поддерживающий OIDC (Keycloak в моём случае) может поддерживать, например, 2fa/client tls auth и подобные радости.
- про
mvn deployвсё более-менее понятно. Он мне местами не очень нравится (в частности, необходимостью дублироватьscmи иметьdistributionManagementв parent'е). Причем, иногда хочется из jenkins'а подтвердить promotion в stage окружение, а далее в release. С jenkins pipeline это вполне реализуемо. Но пока у меня нет устоявшегося представление как это всё будет выглядеть, так что я присматриваюсь к разным вариантам. - В свой сервис обычным http callback'ом (т. е. то, что обычно и понимается под webhook'ом), а он уже может выполнять задачи по уведомлению, используя какой-нибудь slack и т. п. Вполне возможно, что всё может делаться из jenkins'а и придумал себе проблему на пустом месте.
- Он хочет вот это: https://www.jfrog.com/confluence/display/RTF/Single+Sign-on
Как с помощью maven работать с библиотеками, которых в maven нет