LINUX.ORG.RU
ФорумTalks

Как можно жить и пользоваться java, используя maven?

 , , , ,


0

2

Сегодня узнал про maven. Был в ярости, что подход типа «сходить на сайт maven, найти нужный модуль, скопировать строки xml, вставить в зависимости своего проекта» - это ок. Вы серьёзно? Perl миллион лет назад научился в CPAN, который ставит пакет по команде cpan MODULE::NAME.

Почему такую простую и важную вещь в java нормально не реализовали? Или реализовали и про неё мало кто знает?

Я просто в ярости. Если мне потребуется подключить 10-20 модулей - это потребует немало времени. Что за дичь вообще? Это поэтому среднее время разработки софта на java измеряется годами?

★★★★

А в чём проблема-то? Так сложно один раз скопировать 20 кусков текста в один файл?

mono ★★★★★ ()

А CPAN умеет вообще в зависимости к проектам? Или просто глобально все устанавливает? По-моему нормальный подход, добавляешь зависимости и maven/gradle/sbt/cargo/stack скачивает тебе все что надо.

nanosleep2 ()

Ide умеют все это в несколько кликов через gui, и искать по maven и устанавливать любые либы, с исходниками и доками. Если уж maven используешь, то нечего от фич ide нос воротить.

ertgblasd ★★ ()

Потому что все данные в этой XMLке реально нужны.

Если хочешь, можешь сам написать скрипт, который добавляет в dependencies нужную депенденсю. Это реально минут пять. В sbt такая фича есть искаропки, например.

Проблема в том, что обычно в pom находится очень, очень сложный конфиг. В реальном проекте ты ОЧЕНЬ вряд ли будешь что-то добавлять через «cpan MODULE::NAME».

Как минимум ты должен вначале добавить нужную версию зависимости в корневой pom в секцию dependencyManagement (а для плагина - в pluginManagement). Версию лучше не хардкодить в саму dependencyManagement, а вынести в properties и назвать как-нибудь типа «commons.logging.version». Видишь, скрипт начинает разрастаться.

Потом ты добавишь туда инклуды и эксклуды. Профили. Тесты. И многое другое.

Мне кажется, что по сравнению с долгими часами написания конфигов для билда, конкретно твоя проблема совершенно не является бутылочным горлышком. Ты совсем не на то пока смотришь.

Вот например, рекурсивное обновление версий проекта при выпуске релиза (особенно если релиз выходит каждый день), особенно если внутри одного проекта несколько схем нумераций для разных типов модулей, особенно если не всем модулям надо обновлять версии и надо поддерживать список эксклудов - вот это реально дочерта времени занимает. Ибо maven-release-plugin убогий, и я им не пользуюсь, например - обычно пишу свои плагины, которые делают то же самое, но так как мне нужно. Вот это реально долгая, нудная, чреватая ошибками задача. А вставить кусок xml с mvnrepository и это фигня какая-то имхо

stevejobs ★★★★☆ ()

Gradle в этой смысле эргономичне кстати, любая зависимость в одну строчку подключается, и конфигурируется все это не в xml,а на Groovy.

compile 'com.github.bumptech.glide:glide:3.7.0'

ertgblasd ★★ ()

Сегодня узнал про maven

Забудьте и пишите софт на перле. Вас заставляют? Увольняйтесь. Зачем вообще лезть не в свое дело? Софт какой-то, зависимости, сборка... Столько однострочников ещё не написанно, а вы в мавен лазаете. Айяяй.

Weres ★★★ ()

Это поэтому среднее время разработки софта на java измеряется годами?

А теперь прикинь среднее время разработки на С/С++ когда джависты тоговорят тоже самое про компилируемые языки

Siado ★★★★★ ()

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

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

Я всё больше убеждаюсь, что правильно собранный makefile удобнее и прозрачнее в поддержке и обращении, чем все эти хипстерские говноподелия. Даже для джавы. Особенно для джавы.

UPD: нашёл этот проект, это был не maven, а gradle. Ничего не меняет, в принципе.

E ★★★ ()
Последнее исправление: E (всего исправлений: 1)
Ответ на: комментарий от mono

Ты прикалываешься? Это если тебе надо одни и те же модули в каждом проекте. А если разные?

Короче, неудобно, как по мне. Дичь какая-то.

ekzotech ★★★★ ()
Ответ на: комментарий от nanosleep2

Берёшь и ставишь. cpan MODULE::NAME. Потом в проекте use MODULE::NAME.

Претензия к тому, как оно реализовано. Нафига мне топтать батоны чтоб зайти на их сайт и искать модуль на их сайте? Это должно быть реализовано легко, просто и удобно. В 1 команду получить нужный модуль и делов. Их бы предложили ещё вручную переписывать, чтоб прям вообще топчик был.

ekzotech ★★★★ ()
Ответ на: комментарий от coyotl

Не было б необходимости - не было б maven. Просто видать у джавистов это ок так загоняться.

ekzotech ★★★★ ()
Ответ на: комментарий от lenin386

28 минут назад последнее обновление пакета на cpan. Не похож он на мёртвого.

И всё равно cpan удобнее.

ekzotech ★★★★ ()
Ответ на: комментарий от ertgblasd

Не нашёл пока. Если реализовано по-человечески - то ещё куда бы ни шло.

ekzotech ★★★★ ()
Ответ на: комментарий от unt1tled

Ну, я так понимаю, что первый год джависты подключают зависимости.

ekzotech ★★★★ ()
Ответ на: комментарий от ertgblasd

Ну почему-то gradle популярен только для разработки на android. Обычная java до сих пор пользуется maven.

ekzotech ★★★★ ()
Ответ на: комментарий от E

Вот это и удивляет. При количестве разрабов на java там уже давно должна быть тонна различных реализованных инструментов, удобных и быстрых* (*быстрых для java). А тут получается какая-то дичь.

ekzotech ★★★★ ()
Ответ на: комментарий от OldWiseCat

Ну тут дело такое - что другие девелоперы юзают, то и мне придётся юзать.

ekzotech ★★★★ ()
Ответ на: комментарий от ekzotech

Ты прикалываешься? Это если тебе надо одни и те же модули в каждом проекте. А если разные?

Ну вот сделал ты `cpan install` всего, что тебе нужно у себя на компе и спокойно разрабатываешь себе свои 10 проектов. А если тебе нужно сделать их инсталлируемыми через CPAN? Или передать отдать другому разработчику? Ты скорее всего так же опишешь зависимости в каком-то особом перловом виде, нет? В чём принципиальное отличие от мейвена-то с этой стороны?

gagarin ()
Ответ на: комментарий от gagarin

боюсь быть проклятым, но npm i --save module удобно.

dib2 ★★★★★ ()
Ответ на: комментарий от gagarin

В Perl модули объявляются, как правило, в самом начале. Если лень искать - Perl при запуске выкинет ошибку, с указанием, каких модулей не хватает.

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

Но сравни cpan MODULE1::NAME с процессом установки модуля через maven. Должен быть какой-нибудь CJAN, который будет легко и просто ставить модуль, который тебе нужен. Ну либо пользоваться реализацией в IDE (я не знаю, как оно там, до этого ещё не добрался).

ekzotech ★★★★ ()

А в перле можно установить модуль не из cpan? Для конкретного проекта, а не на свою машину? И чтобы потом другой разработчик просто сделал git clone && maven clean install и у него всё собралось?

сходить на сайт maven

Честно, кажется я так никогда не делал. Немало проектов, билдов которых нет в центральном репозитории. Начиная от просто небольших и заканчивая десятко-мегабайтными проприетарными артефактами кровавого интерпрайза. И перед подключением новой зависимости надо ещё подумать 5 раз как это отразится на classpath (тут вам не osgi), сборке и проекте и потом уже «долго копировать четыре строки».

Ну и напоследок, как часто ты создаешь новые проекты, каждый день что ли? Если нет, стоит ответственнее подойти к конфигурации. Тот факт, что там есть какие-то помощники в ide это конечно хорошо, но ни один нормальный разработчик не будет так делать, равно как и использовать какой-нибудь mvn add-artefact, если он даже и есть. Судя по всему, ты пишешь какой-то несложный проект и мавеном стреляешь пушкой по воробьям.

orm-i-auga ★★★★★ ()
Ответ на: комментарий от E

молча полез в интернеты за зависимостями

Ты хочешь собрать проект. Либо ты читаешь README.md, делаешь условный apt install {список из десятков пакетов} для не мавен/ява проекта, попутно решая возникающие конфликты, либо за тебя это делает специальный инструмент. Т.е. ты либо собираешь, либо не собираешь проект.

И в отличие от например rm -rf ~/.m2, (что, кстати, никак не скажется на успешности повторной сборки), удалить ненужные пакеты потом обычно несколько сложнее.

orm-i-auga ★★★★★ ()
Ответ на: комментарий от orm-i-auga

Я с maven только сегодня познакомился. Я его ещё не использовал. Но на мой взгляд его реализация весьма далека от совершенства.

ekzotech ★★★★ ()

Это поэтому

Не чувствуешь стиль родного языка, будь внимательнее.

Sociopsih ★☆ ()
Ответ на: комментарий от ekzotech

Я с maven только сегодня познакомился. Я его ещё не использовал. Но на мой взгляд его реализация весьма далека от совершенства.

Как бы ты отнёсся к человеку, который «только сегодня познакомился с CPAN, ещё не использовал его», и на взгляд которого «его реализация весьма далека от совершенства»?

orm-i-auga ★★★★★ ()
Ответ на: комментарий от orm-i-auga

Вспоминаю, как я впервые познакомился с CPAN. Совершенно другое впечатление. CPAN, можно сказать, это пакетный менеджер. Поскольку я был знаком с пакетными менеджерами в линуксе - для меня не возникло никаких проблем или вопросов в плане удобства использования.

А тут возникло. В случае с maven, я имею ввиду. Вот и создал тред, чтобы понять, вдруг есть нормальные варианты использования, которые будут более удобны.

ekzotech ★★★★ ()
Ответ на: комментарий от ekzotech

Maven - система сборки.

Он умеет выкачивать зависимости для проекта и собирать с минимальными усилиями. Допустим, ты помучился, покопировал куски XMLа в свой pom.xml и с кем-то поделился. Он сделает что-то вроде «mvn package», мейвен, предварительно скачав полинтернета, сделает джарник.

Но Maven - не пакетный менеджер. Если ты добавил зависимость в одном проекте и она скачалась мейвеном (вместе с половиной интернета), то в другом проекте ты не сможешь её заюзать, пока не добавишь кусок XML и туда.

gagarin ()
perl -le '
      $LOVE=               AMOUR.
    true.cards.        ecstacy.crush
  .hon.promise.de    .votion.partners.
 tender.truelovers. treasure.affection.
devotion.care.woo.baby.ardor.romancing.
enthusiasm.fealty.fondness.turtledoves.
lovers.sentiment.worship.sweetling.pure
.attachment.flowers.roses.promise.poem;
 $LOVE=~ s/AMOUR/adore/g; @a=split(//,
  $LOVE); $o.= chr (ord($a[1])+6). chr
   (ord($a[3])+3). $a[16]. $a[5]. chr
    (32). $a[0]. $a[(26+2)]. $a[27].
      $a[5].$a[25]. $a[8].$a[3].chr
        (32).$a[29]. $a[8].$a[3].
          $a[62].chr(32).$a[62].
           $a[2].$a[38].$a[4].
               $a[3].".";
                 print
                  $o'
evilface ★★ ()
Последнее исправление: evilface (всего исправлений: 1)

Не вижу проблем. У мавена другие косяки, скажем то что pom это адский ад если его сознательно не чистить. А зависимости и life cycle - имхо модель мавена лучше чем в той же ноде, более гибкая и в то же время строгая

upcFrost ★★★★★ ()
Ответ на: комментарий от gagarin

в другом проекте ты не сможешь её заюзать

полностью самостоятельные куски кода можно с shade паковать. Мы так делаем когда партнёрам отсылаем сборку

upcFrost ★★★★★ ()
Ответ на: комментарий от E

Без малейших намёков и сообщений он накачал мне полгигабайта говна в домашнюю директорию

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

а настройки - да, есть, рантайм-опциями и env.

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Иногда задумываюсь, и зачем люди идут в программисты...

unt1tled ★★★★ ()
Ответ на: комментарий от E

Makefile? По-твоему удобнее вручную искать и ставить недостающие зависимости после каждого падения сборки, чем запустить mvn clean package, который самостоятельно скачает все зависимости, положит их в кеш, а потом соберет проект?

f1xmAn ★★★★★ ()
Ответ на: комментарий от f1xmAn

удобнее вручную искать и ставить недостающие зависимости после каждого падения сборки

ТС вот пишет, что с maven точно такие же проблемы. Поэтому да, лучше иметь более низкоуровневый, но настраиваемый инструмент, чем очень крутой и навороченный, но тупой и кастрированный.

E ★★★ ()
Ответ на: комментарий от Deleted

ТС, вот этого товарища послушай, дело говорит. Его вброс, кстати, чуть тоньше, чем ты можешь подумать.
Будь ты опытным java-девелопером, скорее всего ты был бы с этим ок. Более того, spring нынче - практически стандарт де-факто. Твое приложение может вести себя по-разному даже в зависимости от dependency в runtime.

bytecode ★★ ()
Ответ на: комментарий от ekzotech

CPAN, можно сказать, это пакетный менеджер.

Мавен — не пакетный менеджер. Управление зависимостями только одна из его задач, конфигурация которых декларативно описывает в pom что нужно делать на разных фазах сборки. Т.е. ты не вручную ставишь пакеты, и не указываешь как их ставить, а лишь указываешь, что именно тебе нужно, для чего, и, при необходимости, где это взять.

orm-i-auga ★★★★★ ()
Ответ на: комментарий от E

Возможно, локация кэша зависимостей где-то настраивается.

да

Но такое поведение по умолчанию - это свинство

ты каких веществ объелся?

сейчас совершенно весь софт держится на зависимостях с Гитхаба. В мире JS, Ruby, Python итп всё то же самое

stevejobs ★★★★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.