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

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

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

небыло необходимости?

Пёрл мёртв. Ты не знал это. Теперь знай.

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

Среднее время разработки любого софта измеряется годами. Ява не исключение.

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

Это не жизнь, это девелопмент

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

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

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

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

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

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

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

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

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

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

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

Нужно задавать правильные вопросы:

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

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

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

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

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

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

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

Попробуй Gradle, там синтаксис groovy, что гораздо приятнее xml

Прочитав твой пост, я ужаснулся и стал ещё больше любить сишечку и autotools

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

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

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

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

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

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

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

Палю годноту: https://start.spring.io/

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

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

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

Niet, нет пути назад. Надо учить.

Вариантов-то не завезли.

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

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

Увы, я не готов осилить сишечку сейчас.

Spring мы будем изучать чуть позже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это поэтому

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

Ну так имакса же хватит всем, ага.

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

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

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

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

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

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

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

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'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да

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

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

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