ГК ЛАНИТ corporate blog
Programming
Java
Build automation
Comments 55
+9
Ну вот зачем вы учите начинающих плохому? )))

Есть менеджеры репозиториев, например nexus и artifactory. У них есть полноценные бесплатные версии, которые (конкретно могу утверждать про nexus, но не думаю что с другими все сильно отличается) устанавливаются и запускаются максимум за полчаса. Есть например готовые docker images, откуда можно запустить вообще без усилий, если у вас есть docker.

И дальше свой nexus надо прописать раз и навсегда в settings.xml, и с ним работать. Если вы не кустарь одиночка с мотором (с), это будет одно из правильных решений. А если вы работаете в команде — то пожалуй и единственно правильное.

Установить и запустить. И дальше все проблемы будут решаться через UI — задеплоить артефакт, которого нет в репозиториях, подключить еще один репозиторий помимо central, и прочее, и прочее.
-1
Ну вот зачем вы учите начинающих плохому? )))
Есть менеджеры репозиториев, например nexus и artifactory.

Я тут совершенно согласен часто нужно класть библиотеки именно туда. В статье об этом есть ремарка :)


И дальше свой nexus надо прописать раз и навсегда в settings.xml, и с ним работать.

А вот тут я считаю, что настройки надо по возможности воткнуть в pom.xml и завернуть в maven профиль, чтобы не было необходимости что-то настраивать в settings.xml


Если вы не кустарь одиночка с мотором (с), это будет одно из правильных решений. А если вы работаете в команде — то пожалуй и единственно правильное.

А если вы в команде — тем более класть в профиль, чтобы не заниматься правкой settings.xml на регулярной основе


Установить и запустить. И дальше все проблемы будут решаться через UI — задеплоить артефакт, которого нет в репозиториях, подключить еще один репозиторий помимо central, и прочее, и прочее.

Это, повторюсь, хороший вариант. В статье я хотел сделать фокус именно на работе с maven. Этот вариант работы, на мой взгляд, описан в пункте про подключение удалённого репозитория.

+2
Да, с поправками насчет settings и пр. — согласен.

Собственно, я имел в виду, что ваши варианты — они конечно да, самые базовые, но в реальности все-таки намного проще настроить репозиторий. В случае компании, которая живет в интранете — это просто must have, без вариантов вообще. И на это стоило бы напирать сильнее.
+2

Я не совсем согласен с такой точкой зрения. Иметь свой корпоративный репозиторий в команде это, конечно же, хорошо и правильно. Но я всегда следую принципу, что проект должен уметь собираться всегда и везде, без лишних геморроев. Локальный репозиторий проекта — разумное решение, когда тебе нужен всего лишь какой-нибудь пропиетарный драйвер. Это делает сборку проекта автономной и независимой от окружения. Maven Wrapper при этом еще отлично помогает.

0
Ну да. Наверное все-таки стоит разделить проекты на open source (которым в первую очередь нужно собираться везде), и скажем так, корпоративные.

Но с другой стороны, для maven же есть средства, которые умеют копировать репозитории целиком. Так что если у вас зависимости лежат скажем на github в виде локального репозитория, перетащить их в nexus будет совсем просто.
+1
Это делает сборку проекта автономной и независимой от окружения. Maven Wrapper при этом еще отлично помогает.

Именно это я и имел в виду. А Maven Wrapper — вещь! Я когда gradlew увидел — долго горевал, что для maven такого нет. Пока через час не выяснил, что вполне себе есть!

+4

Спасибо, дорогой за луч света в этом плотном слое говна. Я тут обфейспалмился до крови, читая этот ад (я про статью, конечно). У Artifactory тоже есть бесплатный оpensource, конечно. У нас есть генератор settings.xml, который вообще делает всё за тебя: https://www.youtube.com/watch?v=MGXrPz9wwOY


Кроме того, у нас есть еще и Maven plugin, который добавляет metadata к задеплоенным артифактам.

0
mvn deploy:deploy-file

А потом вы ошибаетесь в -Dpackaging=pom и записываете вместо pom — jar. Поздравляю — у вас битый локальный репозиторий и теперь резолв артефакта будет идти с ошибкой.
-3

Это же попадёт в систему контроля версий. Можно будет по коммиту найти виноватых, наказать невиновных и наградить непричастных :)

+1
Не попадет. Если только вы не храните локальный репозиторий под версионным контролем.
0

Есть одна проблема с локальным репозиторием — для мультимодульного проекта придется корректировать путь к нему в каждом pom.xml, так как project.badedir будет у каждого модуля свой.

-1
Есть одна проблема с локальным репозиторием — для мультимодульного проекта придется корректировать путь к нему в каждом pom.xml, так как project.badedir будет у каждого модуля свой.

Есть, да. Многомодульному проекту в maven вообще хочется посвятить отдельную публикацию — очень уж актуальная и важная тема.

0
К слову, maven уже 15 лет и означает собиратель знаний
Это к тому, что уже давно все собрано в смысле знаний о самом maven и его использовании
+1

Да 15 лет и такое впечатление что он нисколько не изменился за эти 15 лет, да и просто не может меняться.

+1

Ньютоновской физике даже больше 15, а учебники всё пишут и пишут :). Я попытался написать статью именно такой, какой хотел видеть её, когда про maven ещё ничего не знал. Написал с надеждой, что найдутся люди, которым будет удобно получить знания именно в такой форме.

+2
Найдутся! В смысле — уже нашлись :) Пишите, пожалуйста, еще. Мавен — это инструмент, и им, как и любым инструментом, хочется «просто пользоваться» не затрачивая массу усилий на то что б понять, как же эту хреновину уже заставить работать и перейти к тем проблемам, из-за которых все тут собрались — собственно к программированию.
-3
А гораздо проще сделать это так:

maven { url 'https://jitpack.io' }

dependencies {
compile 'com.github.jehy:Tor-Onion-Proxy-Library:0.0.5'
}


И вот у вас прямо из гитхаба идёт импорт.
+1

Во-первых это не совсем maven :). А во-вторых импорты с гитхаба штука опасная, если он конечно не твой собственный.

-1
Во-первых, не вижу разницы для разработчика.
Во-вторых, никто не отменял форки.
+1

Ну, тема статьи всё-таки 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>

Действительно неплохой способ. Собирать библиотеки только нужно, но для многих это скорее плюс, чем минус. Жаль только завязан на проприетарную технологию с закрытым кодом. А так — вполне себе.

0

repository в pom.xml это действительно не всегда хорошо. Однако, в приведённой вами статье написано, что в случае, если продуктом является программа, которую не собираются использовать в качестве зависимости, то указание репозитория в помнике вполне безопасно. И, если вы хотите упростить сборку проекта для других разработчиков эта идея вполне заслуживает рассмотрения. Именно о таких кейсах я говорил. Спасибо за замечание, добавил уточнение в статье.

0

Особенно весело видеть в конечном приложении такой repository, который требует аутентификации ,)

0
В приведенной мной статье, персонажи, которые придумали этот ад изначально, пытаются оправдаться в стиле «да, это конечно ужас, но не ужас-ужас». Repository в pom это bad practice, и точка. Settings.xml всё равно надо будет генерить для каждого разработчика (потому что там их личные credentials), поэтому нет никаких проблем держать там репозитории тоже.
0
А, вы про то, что это Gradle. Да, моя ошибка. Думал, будет всем понятно и так…
+3
Но, если это возможно, такую библиотеку лучше положить в проект и хранить прямо в системе контроля версий. Тогда библиотека будет доступна программе всегда и на любой машине, а шаг по копированию этой библиотеки в репозиторий можно не включать в мануал.

А вот так делать не надо!!! Есть грань между SCM и binary repository manager которую не следует путать. Свой собственный корпоративный репозитарий — правильное решение. Хранение библиотек в SCM — грязный хак!
0
А вот так делать не надо!!! Есть грань между SCM и binary repository manager которую не следует путать.

Вопрос в том, где эта грань. Тут как с картинками и всем таким. Если у вас их пара гигабайт, то нужно хранить отдельно. Хотя всякое бывает :). А, если пара иконок, то обычно хранят прямо в системе контроля версий. С библиотеками похожая ситуация. Если есть один проприетарный драйвер, или небольшой джарник из эпохи мамонтов с утерянными исходниками — то можно и прямо в исходники положить. А если там целая система с зависимостями, то лучше как-то по другому делать.


Свой собственный корпоративный репозитарий — правильное решение.

Особенно, если у вас есть своя собственная корпорация :). А если у вас свой проектик с парой джарников, то корпоративный репозиторий возможно и оверкилл.


Хранение библиотек в SCM — грязный хак!

Может и так, но в гите оптимизации для хранения бинарников появились не от того, что разработчикам просто нечего было делать.

+1
Свой репозиторий оверкилл только если результат проекта вам почти совсем не важен. А если важен — то репозиторий все равно понадобится. В идеале — положить в central. И потом — это в конечном счете быстрее, иметь свой кеш внутри команды.

А про хранение внутри SCM — я бы сказал так: хранить можно, но желательно даже в этом случае разделить репозитории. Пусть у вас будет git repo — но отдельный и только для артефактов. У них другой жизненный цикл, чем у ваших исходников, вы не будете делать такие же бранчи, релизить, и прочее и прочеее. А значит — разделить.
+1
А если у вас свой проектик с парой джарников, то корпоративный репозиторий возможно и оверкилл.

Для проектов с открытым исходным кодом можно использовать центральный репозитарий. Тогда ваши артефакты могут указывать в зависимостях без подкладываний jar в SCM или deploy в корпоративный репозитарий. Есть nexus opensource edition и установка простая — скачал и запустил. Если же проект не open source и вам лень ставить свой менеджер репозитариев и делать бэкапы, то можете раскошелиться на подписку bintray и использовать как сервис для не общедоступного репозитария.

Может и так, но в гите оптимизации для хранения бинарников появились не от того, что разработчикам просто нечего было делать.

По мне так ответ проще — для хранения jpg/png для веб приложений, которых огромное число в github.
0
Если же проект не open source и вам лень ставить свой менеджер репозитариев и делать бэкапы, то можете раскошелиться на подписку bintray и использовать как сервис для не общедоступного репозитария.

Тут уже, думаю, вопрос личных предпочтений. Если вы считаете, что ради того, чтобы положить пару джарок в проект имеет смысл поставить Нексус или купить подписку на bintray, то, конечно надо так и делать. Я бы задумался об этом после того, как понял, что джарки придётся регулярно обновлять.

0

И кстати, Артифактори подходит гораздо больше, и он бесплатен.

0
А что не так с bintray? Это же и есть репозиторий, в общем-то.

Что же до SCM — то есть помнится возможность деплоить туда артефакты при помощи штатного механизма — т.е. mvn deploy. При этом SCM у вас играет роль хранилища, но работаете вы с ним как с репозиторием.

Я бы сказал, что такой подход — он ограниченно годится, но в тоже время совершенно ясно, что он даже не столько от бедности, сколько от лени. Ну опять же — потому что трудозатраты на установку своего репозитория они настолько маленькие, что это даже не смешно.

У меня вот в проекте (предыдущем на сегодня) был (и есть) nexus. Тому нексусу — наверное лет 6 или 10 уже. Никого из тех, кто его развертывал, уже давно в компании нет. Рядом, если что, такой же дремучий jenkins. Никто их не поддерживает — разве что время от времени чистят диск от ненужных сборок jenkins. И работают с этим добром человек 20. Вот такие они — трудозатраты, по стоимости машинки для запуска (виртуалка на два ядра и 8Гб) и диска для размещения всего добра, гигабайт на 100.
0

С бинтреем всё так, но он просто не для разработки, а для дистрибуции. Для разработки больше Артифактори подходит. Мы в Разборе Полётов всё таки когда нибудь доберемся до разницы между ними (но не в следущем выпуске точно).

+1
Тут понимаете еще какая штука… Сначала пара jar, потом десять. А потом будет как в одном моем старом проекте — огромная папка lib, одна на 50 проектов, и порядка 50-же разработчиков.

И валяется там на 99% вполне себе open source, типа commons collections, и огромная проблема со всем этим состоит в том, что никто уже не знает, какому проекту на самом деле какие завимости нужны, кто от кого зависит, какие у них версии, и прочая и прочая.

Там правда к этому еще прилагался ant, но разница в общем не очень велика, потому что главная проблема не в том, чем собирать, а в том, что где-то в lib лежит нечто, о чем мы не знаем, как его точно зовут, и какой оно версии. И если завтра кто-то заменит в SCM один jar на другой, похожий — мы долго будем думать, почему оно вдруг сломалось.
0

Всё-таки central — репозиторий по умолчанию для maven'а, а jcenter надо явно прописывать в settings.xml или добавлять в группу в nexus/artifactory. С остальным сложно не согласиться ,)

0

Да, но с генераторами сеттингов и в Бинтрее и в Артифактори это достаточно просто.

+4

Что же вы делаете-то?! Tutorial в корпоративном блоге предлагает "Директорию lib надо закомитить и библиотека будет доступна проекту вообще всегда"? Я думаю следущая статья должна быть о том, как сорцы лучше пересылать по email-у.

+3

К сожалению, эта тенденция в большинстве корпоративных блогов на хабре. Есть исключения (в особенности среди больших корпоратов типа mailru/yandex/ibm), но большинство тупо получает деньги за количество знаков, а не качество, вот и прёт индусятина в новом обличье.

+1

Не все индусы одинаково полезны. Я знаю некоторое количество тех, кто реально неплохой код пишет и поддерживает. Но иногда с ужасом вспоминаю исходники какого-нибудь Atlassian Crowd'а.

0

Как и не все русские, и не все американцы, я бы сказал. Особенно в свете обсуждения качества статей на Хабре.

+1

Стереотип не на пустом месте появился, и отсылка была именно к нему, а не к национальности.


Проблема-то та же самая, многим копирайтерам платят за объём и частоту публикаций, а не за качество, так что результат немного предсказуем.

0

@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 варианте.

+1
  • В бесплатном есть только LDAP
  • Это конечно всё есть, и через Artifactory Jenkins Plugin, и через Artifactory Maven Plugin (оба open source) и просто через mvn deploy
  • Это через user plugin, который в Pro.
0

Понятно, спасибо. Т. е. в теории вполне реально, если всё делать со стороны jenkins'а. Надо пробовать.


В планах sso/oidc отдать в opensource нет? То у меня есть впечатление, что раньше ldap был только в pro. И аналогичный вопрос про docker-репозитории.

0
ldap всегда был в open-source. Планов переносить что-то из pro пока нет.
0
Пардон, мне кажется, или вы хотите странного?

1. Вы когда деплоите, вы скорее всего используете http, и один из стандартных механизмов аутентификации юзера. Basic, NTLM, SSL. Чтобы использовать тут внешнюю, нужно допилить maven deploy plugin, а точнее видимо вагон. Внешняя тут зачем, чтобы использовать ее в этом месте вместо LDAP? Тогда это Artifactory Security Realm (ровно также, как у nexus впрочем). Это не очень сложно, я пробовал.
2. Проще всего mvn deploy, разумеется. Остальное дополнительные плюшки.
3. В nexus для этого есть RSS и расылка нотификаций почтой. Как вы хотите получать уведомления, если это асинхронный процесс? Чей это должен быть REST? Jenkins, чтобы он собрал другой зависимый артефакт?
0

Не то чтобы очень странного ,)


  1. Я не против использования http authn для деплоя (из jenkins'а или из maven/gradle/sbt — не важно), но для работы с самим artifactory/nexus хочется иметь поменьше геморроя, в частности SSO. OIDC в этом плане является стандартом наравне с более сложным и неприятным SAML, который мне сильно избыточен. И сервер авторизации, поддерживающий OIDC (Keycloak в моём случае) может поддерживать, например, 2fa/client tls auth и подобные радости.
  2. про mvn deploy всё более-менее понятно. Он мне местами не очень нравится (в частности, необходимостью дублировать scm и иметь distributionManagement в parent'е). Причем, иногда хочется из jenkins'а подтвердить promotion в stage окружение, а далее в release. С jenkins pipeline это вполне реализуемо. Но пока у меня нет устоявшегося представление как это всё будет выглядеть, так что я присматриваюсь к разным вариантам.
  3. В свой сервис обычным http callback'ом (т. е. то, что обычно и понимается под webhook'ом), а он уже может выполнять задачи по уведомлению, используя какой-нибудь slack и т. п. Вполне возможно, что всё может делаться из jenkins'а и придумал себе проблему на пустом месте.
Only those users with full accounts are able to leave comments.  , please.