Comments 36
А зачем, если есть Gradle?
На вкус и цвет все фломастеры разные :) Вот тут мой ответ на твит от @CedricChampeau. Кратко — Maven мне нравится своей стройной моделью проекта. Я считаю, что рамки, которая она накладывает, это плюс, а не минус.
Ну на мой взгляд, это как раз не аргумент.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке. Gradle предоставляет золотую середину между сложностью написания таких скриптов и автоматизированным выполнением рутинных задач.
Maven в свою очередь экстремально декларативен, и если не дай б*г надо что то сделать нестандартное (структура проекта, жизненный цикл сборки и т.п.), то мавен принесет много боли.
Опять же имхо, в 21 веке будущее за гибкостью.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке. Gradle предоставляет золотую середину между сложностью написания таких скриптов и автоматизированным выполнением рутинных задач.
Maven в свою очередь экстремально декларативен, и если не дай б*г надо что то сделать нестандартное (структура проекта, жизненный цикл сборки и т.п.), то мавен принесет много боли.
Опять же имхо, в 21 веке будущее за гибкостью.
Так, а я о чём? :) Gradle отличный продукт, и не от балды его придумали, а пытаясь решить реальные проблемы. Скорее всего вызванные попыткой «сделать нестандартное». Вот только, для меня сам факт таких проблем, это звоночек, что я делаю, что-то не совсем так и повод решить возникшую проблему немного иначе. A нестандартных подходов я видел много, ещё когда с ANT работал. И всё хорошо, когда сам пишешь этот скрипт, но вот когда его пишет кто-то другой, а тебе надо кусочек поправить. Кто сталкивался, тот поймёт.
И всё хорошо, когда сам пишешь этот скрипт, но вот когда его пишет кто-то другой, а тебе надо кусочек поправить.
Так в этом все и дело… Gradle нашел золотую середину и поэтому Maven остается не у дел, как в свое время оставался не удел Ant. Мир меняется, концепция тоже, а мы (разработчики) как двигатели должны использовать самое лучшее что придумано.
Поэтому фраза про фломастеры мне показалось плохим аргументом в пользу мавена. Gradle объективно более удачный инструмент => на него следует переходить и, отдав должные почести, оставить уже мавен в покое.
А… Ну хорошо, что он её нашел. Я же писал, в основном, для тех, кто продолжает «мучиться» с maven по разным причинам. Кому-то он достался в наследство, кто-то сделал осознанный выбор и использует maven или Gradle не потому, что кому-то «должен», а просто потому, что своя голова на плечах есть.
Так не интересно, никаких аргументов с вашей стороны нет :(
Приведите, если не трудно, преимущества или недостатки одного над другим.
«Гибкость» в вашем твите это скорее преимущество градла, чем недостаток. Гибкость позволяет сделать то же самое, но с заделом под изменяющиеся условия.
Мне действительно интересно, потому что сталкивался не раз с адептами, которые с пеной у рта доказывают, что лучше мавена ничего нет и не было, и тащат его во все проекты. При этом какой-то внятной позиции добиться не удалось…
Вы не подумайте, я не адепт градла, если завтра выйдет тулза MavGradle, которая будет лучше работать и лучше подходить моим задачам, я стремительно туда перейду. Ну по-моему просто мавен уже морально устарел по приведенным мной выше аргументам.
Приведите, если не трудно, преимущества или недостатки одного над другим.
«Гибкость» в вашем твите это скорее преимущество градла, чем недостаток. Гибкость позволяет сделать то же самое, но с заделом под изменяющиеся условия.
Мне действительно интересно, потому что сталкивался не раз с адептами, которые с пеной у рта доказывают, что лучше мавена ничего нет и не было, и тащат его во все проекты. При этом какой-то внятной позиции добиться не удалось…
Вы не подумайте, я не адепт градла, если завтра выйдет тулза MavGradle, которая будет лучше работать и лучше подходить моим задачам, я стремительно туда перейду. Ну по-моему просто мавен уже морально устарел по приведенным мной выше аргументам.
Ну вот нет у меня этих аргументов. Не сердитесь :) Просто maven это инструмент, который меня пока сильно не подводил. Что бы понять билд чужого проекта надо просто знать мавен, а не заниматься reverse engineering. Я не говорю, о том, как вносить исправления — ведь для этого придётся не просто понять, что делает данный скрипт, но и зачем он это делает, и какая идея за этим стоит.
В то время как у maven модель фиксированная, что значительно облегчает работу с проектами. Опять же юниор на проекте не успееет много сломать. Можно вовремя его поправить.
В то время как у maven модель фиксированная, что значительно облегчает работу с проектами. Опять же юниор на проекте не успееет много сломать. Можно вовремя его поправить.
Ну все еще впереди :) Могу описать свои проблемы:
1) Жесткая структура убивает многомодульные проекты со сложной иерархией.
2) Документация в многомодульных проектах генерируется отвратно и слабо настраивается (отчеты checkstyle, PMD, javadoc)
3) Нельзя положить исходники соседнего проекта и организовать билд-цепочку (при изменении в одном модуле ребилдить другой)
4) Нельзя настроить жизненный цикл по своему усмотрению
5) Если надо настроить сложный билд для нескольких языков, приходится юзать Ant с запуском настоящих билд скриптов :)
В моем случае речь не о новичках и сложности при анализе билд-скриптов, а сугубо инженерные проблемы. Хотя если опять же проект достаточно сложный, то читать и анализировать помник на пару тысяч строк, тоже то еще удовольствие…
1) Жесткая структура убивает многомодульные проекты со сложной иерархией.
2) Документация в многомодульных проектах генерируется отвратно и слабо настраивается (отчеты checkstyle, PMD, javadoc)
3) Нельзя положить исходники соседнего проекта и организовать билд-цепочку (при изменении в одном модуле ребилдить другой)
4) Нельзя настроить жизненный цикл по своему усмотрению
5) Если надо настроить сложный билд для нескольких языков, приходится юзать Ant с запуском настоящих билд скриптов :)
В моем случае речь не о новичках и сложности при анализе билд-скриптов, а сугубо инженерные проблемы. Хотя если опять же проект достаточно сложный, то читать и анализировать помник на пару тысяч строк, тоже то еще удовольствие…
1. Я возможно вас обижу, наверное, но сложная иерархия в многомодульных проектах часто возникает из-за ошибок проектирования, а с простой иерархией maven справляется на раз.
2. Ничего не могу сказать — вполне возможно, что это и так. Я документацию не генерирую, а когда приходилось по работе (проект из 10-20 модулей) никогда проблем не было. Правда мы её настраивать не пытались :) Результат «из коробки» нас вполне устроил.
3. Не очень понял :) Куда положить? У меня проекты через 2-3 транзитивные зависимости вполне внятно работают с исходниками (для GWT надо) Где организовать? IDE сама разбирается, CI сервер тоже (хотя я это сейчас не использую)
4. Можно, но сложно (очень сложно) — и это плюс IMHO
5. А вот тут я с вами соглашусь, пожалуй. Maven это только для Java.
2. Ничего не могу сказать — вполне возможно, что это и так. Я документацию не генерирую, а когда приходилось по работе (проект из 10-20 модулей) никогда проблем не было. Правда мы её настраивать не пытались :) Результат «из коробки» нас вполне устроил.
3. Не очень понял :) Куда положить? У меня проекты через 2-3 транзитивные зависимости вполне внятно работают с исходниками (для GWT надо) Где организовать? IDE сама разбирается, CI сервер тоже (хотя я это сейчас не использую)
4. Можно, но сложно (очень сложно) — и это плюс IMHO
5. А вот тут я с вами соглашусь, пожалуй. Maven это только для Java.
Добавлю свои 5 копеек:
1 — практических проблем с многомодульными проектами в Maven нет, могут быть исключительно архитектурные проблемы, но с ними без костыляния и Gradle не справится.
2 — Нет никаких проблем с настройкой документации — тут вам и doxygen для специфичных видов документации, и velocity, и docbook, а оборачивается это все через пару плагинов — javadoc, site-plugin, дальше лишь решаете в каком виде вы получить это хотите.
3 — Весьма сомнительная ситуация, когда вы вместо скомпилированной зависимости проекта хотите использовать ее сборку в процессе билда — если она используется только в текущем проекте, внедрите ее как модуль, если же она используется и в других проектах, наиболее логично будет предоставить ей свой релизный цикл и устанавливать взаимоотношения через бинарные зависимости.
4 — ИМХО lifecycle Maven содержит все возможные стадии жизни исходного кода и отхождение от него также указывает на какую-то архитектурную, либо логическую ошибку в процессе сборки, другой момент, когда вы хотите вместить какую-нибудь специфичную для проекта операцию на той или иной стадии цикла, то вы просто используете фазы сборки. Мне сложно представить ситуацию когда генерация кода должна идти после компиляции, но и это не проблема, перекиньте исполнение плагина на соответствуюшую фазу и вуаля. Кроме того, если уж вам действительно необходимо это сделать, напишите свой плагин и сделайте extend на ту или иную фазу цикла, вот вам и кастомное поведение.
5 — Прекрасно все настраивается, лично писал сборку для SDK под одну платформу, где и C/C++, C#, Android с NDK, lua, Flex и т.д.
На одной из конференций был адвокат Gradle, который 1 час потратил на то, чтобы рассказать какие есть у Gradle рюшечки относительно Maven, но реальных технических оснований для перехода так и не озвучил — вот здесь есть такой красивый отчетик, вот тут оно в демоне собирается(но иногда демон подвисает и его надо жестко убивать). Все то, что он в итоге рассказал в сравнении с Maven реально просто делается и на Maven, на мой прямой вопрос почему он это сделал только с Gradle, ответом было, что он не знал что это можно сделать в Maven.
Как-то я приводил уже на хабре ссылку на проект собираемый Maven с количеством модулей 100+, с документацией, к сожалению, на чистой Java, но приведу еще один раз, на всякий случай — github.com/vporoxnenko/mbsa
P.S. Вы не любите кошек? — Да вы просто не умеете их готовить.
P.P.S. Единственное достоинство Gradle, которое я действительно оценил, это инкрементальная компиляция, которая работала стабильнее чем реализация от takari-lifecycle-plugin пару лет назад.
1 — практических проблем с многомодульными проектами в Maven нет, могут быть исключительно архитектурные проблемы, но с ними без костыляния и Gradle не справится.
2 — Нет никаких проблем с настройкой документации — тут вам и doxygen для специфичных видов документации, и velocity, и docbook, а оборачивается это все через пару плагинов — javadoc, site-plugin, дальше лишь решаете в каком виде вы получить это хотите.
3 — Весьма сомнительная ситуация, когда вы вместо скомпилированной зависимости проекта хотите использовать ее сборку в процессе билда — если она используется только в текущем проекте, внедрите ее как модуль, если же она используется и в других проектах, наиболее логично будет предоставить ей свой релизный цикл и устанавливать взаимоотношения через бинарные зависимости.
4 — ИМХО lifecycle Maven содержит все возможные стадии жизни исходного кода и отхождение от него также указывает на какую-то архитектурную, либо логическую ошибку в процессе сборки, другой момент, когда вы хотите вместить какую-нибудь специфичную для проекта операцию на той или иной стадии цикла, то вы просто используете фазы сборки. Мне сложно представить ситуацию когда генерация кода должна идти после компиляции, но и это не проблема, перекиньте исполнение плагина на соответствуюшую фазу и вуаля. Кроме того, если уж вам действительно необходимо это сделать, напишите свой плагин и сделайте extend на ту или иную фазу цикла, вот вам и кастомное поведение.
5 — Прекрасно все настраивается, лично писал сборку для SDK под одну платформу, где и C/C++, C#, Android с NDK, lua, Flex и т.д.
На одной из конференций был адвокат Gradle, который 1 час потратил на то, чтобы рассказать какие есть у Gradle рюшечки относительно Maven, но реальных технических оснований для перехода так и не озвучил — вот здесь есть такой красивый отчетик, вот тут оно в демоне собирается(но иногда демон подвисает и его надо жестко убивать). Все то, что он в итоге рассказал в сравнении с Maven реально просто делается и на Maven, на мой прямой вопрос почему он это сделал только с Gradle, ответом было, что он не знал что это можно сделать в Maven.
Как-то я приводил уже на хабре ссылку на проект собираемый Maven с количеством модулей 100+, с документацией, к сожалению, на чистой Java, но приведу еще один раз, на всякий случай — github.com/vporoxnenko/mbsa
P.S. Вы не любите кошек? — Да вы просто не умеете их готовить.
P.P.S. Единственное достоинство Gradle, которое я действительно оценил, это инкрементальная компиляция, которая работала стабильнее чем реализация от takari-lifecycle-plugin пару лет назад.
1 — К сожалению есть. Как раз в проектах со сложной иерархией (мой опыт). Кивать на архитектуру, мне кажется, не стоит, именно потому что сам инструмент заставляет использовать жесткое построение модулей. И получается, что инструмент влияет на архитектуру приложения. Градл в свою очередь дает простор для творчества в этом смысле — пиши программу которая соберет твою :)
2 — А вот и есть. Пробовал в многомодульном проекте со сложной иерархией прикрутить site-pulgin в связке с Swagger. Не разрешимая проблема это перекрестные ссылки между модулями по REST API, javadoc и др. Мавен просто не дает таких опций. А если нет сквозной навигации, зачем тогда вообще делать такой плагин?
3 — Почему? У меня есть сторонняя либа, которая разрабатывается соседней командой. Я не хочу поднимать общий мавеновский репозиторий для них, но хочу получать правки по определенным тегам из VCS, чтобы получать нужный мне API.
4 — Я лично с такой проблемой не сталкивался, просто слышал стоны своих коллег :) Однако, я хочу написать свой сборочный шаг (не важно фазу или шаг ЖЦ), чтобы он был написан в виде программы, потому что компиляция сложная для этого проекта. Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
5 — Ага, и что вы использовали из мавеновского арсенала? Вангую, что Ant :)
Адепты тех или иных инструментов есть всегда. Если инструмент может порешать мою боль, я им с радостью воспользуюсь. Мавен тем не менее крут своим репозиторием, тут этого не отнять…
Про проект с 100+ модулей — я открыл корневой помник… 1700 строк… Интересно (без сарказма), как будет выглядеть градловский скрипт сборки.
P.S. я с мавеном жил много много лет, готовить я его умею, но прогресс же не стоит на месте.
2 — А вот и есть. Пробовал в многомодульном проекте со сложной иерархией прикрутить site-pulgin в связке с Swagger. Не разрешимая проблема это перекрестные ссылки между модулями по REST API, javadoc и др. Мавен просто не дает таких опций. А если нет сквозной навигации, зачем тогда вообще делать такой плагин?
3 — Почему? У меня есть сторонняя либа, которая разрабатывается соседней командой. Я не хочу поднимать общий мавеновский репозиторий для них, но хочу получать правки по определенным тегам из VCS, чтобы получать нужный мне API.
4 — Я лично с такой проблемой не сталкивался, просто слышал стоны своих коллег :) Однако, я хочу написать свой сборочный шаг (не важно фазу или шаг ЖЦ), чтобы он был написан в виде программы, потому что компиляция сложная для этого проекта. Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
5 — Ага, и что вы использовали из мавеновского арсенала? Вангую, что Ant :)
Адепты тех или иных инструментов есть всегда. Если инструмент может порешать мою боль, я им с радостью воспользуюсь. Мавен тем не менее крут своим репозиторием, тут этого не отнять…
Про проект с 100+ модулей — я открыл корневой помник… 1700 строк… Интересно (без сарказма), как будет выглядеть градловский скрипт сборки.
P.S. я с мавеном жил много много лет, готовить я его умею, но прогресс же не стоит на месте.
5 — maven-nar-plugin, android-maven-plugin, flexmojos-maven-plugin, exec-maven-plugin, ue4-maven-plugin(самописный)
Относительно корневого пома, лишь отчасти согласен, все дело в том, что он передает абсолютно все параметры настройки как плагинов, так и зависимостей, в частности чтобы избежать jar-hell, а также для конфигурации всего проекта из единого файла, и такая конфигурация в Gradle содержала бы не намного меньше параметров и строчек кода и только благодаря прямому указанию параметров в одной строке, например зависимостей, но не более того — я знаю это потому что писал многомодульные проекты как на одном так и на другом.
Обратите внимание лучше на подмодули проекта, например github.com/vporoxnenko/mbsa/blob/master/server/document/pom.xml и его подмодуль github.com/vporoxnenko/mbsa/blob/master/server/document/ui/pom.xml — они достаточно компактны именно благодаря большому корневому pom'у и наследованию параметров от вышестоящих объектов, в компаниях же данную проблему решает superpom, который не было смысла выделять в данном проекте.
Для примера, superpom в моей компании содержит 800 строк, тогда как наследуемые проекты и парент-помы подпроектов компании, благодаря ему не более 300.
Относительно корневого пома, лишь отчасти согласен, все дело в том, что он передает абсолютно все параметры настройки как плагинов, так и зависимостей, в частности чтобы избежать jar-hell, а также для конфигурации всего проекта из единого файла, и такая конфигурация в Gradle содержала бы не намного меньше параметров и строчек кода и только благодаря прямому указанию параметров в одной строке, например зависимостей, но не более того — я знаю это потому что писал многомодульные проекты как на одном так и на другом.
Обратите внимание лучше на подмодули проекта, например github.com/vporoxnenko/mbsa/blob/master/server/document/pom.xml и его подмодуль github.com/vporoxnenko/mbsa/blob/master/server/document/ui/pom.xml — они достаточно компактны именно благодаря большому корневому pom'у и наследованию параметров от вышестоящих объектов, в компаниях же данную проблему решает superpom, который не было смысла выделять в данном проекте.
Для примера, superpom в моей компании содержит 800 строк, тогда как наследуемые проекты и парент-помы подпроектов компании, благодаря ему не более 300.
По пункту 3. — потому что вместе с исходниками соседнего проекта вы хотите притащить в свой еще и знание о том, как их собирать.
В этом месте вы хотите плохого. Не хочу осуждать, потому что для этого надо реально лучше знать ваш проект, но такие желания не следует поддерживать системой сборки.
Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
Хм. То есть, писать всю сборку на груви вам не в лом, а написать плагин (по простым правилам) почему-то не нравится? Это как-то неправильно тоже, не находите? Ну или не так — может это и правильно, но в такой формулировке это выглядит как чистая вкусовщина. Все имеют право на то, чтобы выбирать инструмент, но тогда надо так и формулировать — что это вкусы?
Gradle нашел золотую середину и поэтому Maven остается не у дел
Голословное утверждение. Либо приведите какое-то подтверждение в виде статистики.
Есть куча кейсов, которые простейшим образом покрываются с помощью Maven: добавить зависимости, сконфигурировать плагины, получить свой JAR/WAR и забыть. Причем все это будет в стандартном и понятном каждому виде, а не порождением чьего-то мутного сознания в стиле «привет-Ant».
Нет никакой необходимости в гибкости там, где от нее никакого проку.
Ну давайте возьмем несколько первых ссылок в гугле, например dzone.com/articles/gradle-vs-maven
Сравните объем файлов декларативного мавена и процедурного градла по простейшему билду.
Сравните объем файлов декларативного мавена и процедурного градла по простейшему билду.
Непонятно, каким образом это подтверждает утверждение «Maven не у дел».
Вы вырвали фразу из контекста, перечитайте всю ветку обсуждений
Причем здесь вся ветка? Я попросил вас обосновать ваше крайне сильное и голословное утверждение. Голословное, т.к. общеизвестно, что несмотря на всю чудесность Gradle и десятилетний возраст этого проекта, adoption у Maven выше в разы и не снижается.
Собственно, наглядная иллюстрация «Maven не у дел»:
PS
Не обязательно срать в карму, когда аргументы отсутствуют.
Собственно, наглядная иллюстрация «Maven не у дел»:
PS
Не обязательно срать в карму, когда аргументы отсутствуют.
Вот я же говорю, что вы фразу из контекста выдрали. Я не говорил про долю рынка мавена, а говорил только о наборе функционала и гибкости, и в этом сравнении мавен очевидно проигрывает и, как я выразился, «остается не у дел».
P.S. я к вам в карму не лез, такой ерундой не занимаюсь.
P.S. я к вам в карму не лез, такой ерундой не занимаюсь.
Инструмент должен решать задачи, адекватным способом, а не предоставлять «набор функционала и гибкости». Проигрывает Maven или не проигрывает это вопрос дискуссионный, а вот то, что он покрывает множество типичных сценариев без какой-либо головной боли – очевидно. Как же очевидно и то, что для некоторых случаев предлагаемый им подход может быть неудобен.
Поэтому я совершенно не понимаю, что должна означать фраза «остается не у дел», когда Maven успешно решает задачи для множества разработчиков и проектов.
Поэтому я совершенно не понимаю, что должна означать фраза «остается не у дел», когда Maven успешно решает задачи для множества разработчиков и проектов.
Еще раз только могу повторить — плагины для мавена пишутся просто. Более того, при большом желании, и небольшими усилиями вы вполне можете притащить в них всю (или почти всю) функциональность плагинов gradle, потому что это не более чем классы. И гибкость тоже никто не ограничивает. Вы вполне можете писать плагины, которым вообще не нужен POM, вы можете брать информацию для сборки откуда угодно, и пользоваться любыми инструментами.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке.
Кому они должны, и почему? И вы видимо не слышали про gmaven, например? Там все ровно также, как в gradle (и да, я работал с обоими, если что). И плагины к мавену пишутся вовсе не сложно (и опять же да, я написал с десяток-другой). Нет там никакой боли, воообще. Любая структура проекта, включая никакой (плагины, которым не нужен POM, на минутку, существуют). Все эти сказочки про боль расширения мавена явно написаны теми, кому все равно лень изучить groovy.
Скорость сборки?
Чтобы POM не занимал несколько экранов, надо использовать Polyglot Maven.
Хорошая идея, но есть несколько причин, почему я им пока не пользуюсь. Это поддержка, точнее её отсутствие, в Eclipse. Плюс, как-то у меня не получилось сходу подобрать правильный диалект, который бы мне понравился. Ну и для статьи, по любому, лучше использовать native language, то есть XML.
Нравится дело субъективное, но:
Можно в одну строчку писать, если хочется.
dependencyManagement:
dependencies:
- groupId: org.checkerframework
artifactId: checker-qual
version: 2.1.10
- groupId: org.checkerframework
artifactId: checker
version: 2.1.10
- groupId: org.checkerframework
artifactId: jdk8
version: 2.1.10
Можно в одну строчку писать, если хочется.
DEL
UFO just landed and posted this here
Честно говоря — нет у меня такого опыта, первое, что я сделал, когда смотрел на spring boot, это можно ли его использовать без их parent POM. Оказалось, что да, и дальше я не копал :)
UFO just landed and posted this here
Sign up to leave a comment.
Идеальный мавен. Часть 1