Грустно смотреть как умирает наш космос. И частники не спасут.
Я помню ваши публикации несколько лет назад, где говорилось, что еще не все потеряно, надо просто подождать. Ну вот и дождались…
1 — К сожалению есть. Как раз в проектах со сложной иерархией (мой опыт). Кивать на архитектуру, мне кажется, не стоит, именно потому что сам инструмент заставляет использовать жесткое построение модулей. И получается, что инструмент влияет на архитектуру приложения. Градл в свою очередь дает простор для творчества в этом смысле — пиши программу которая соберет твою :)
2 — А вот и есть. Пробовал в многомодульном проекте со сложной иерархией прикрутить site-pulgin в связке с Swagger. Не разрешимая проблема это перекрестные ссылки между модулями по REST API, javadoc и др. Мавен просто не дает таких опций. А если нет сквозной навигации, зачем тогда вообще делать такой плагин?
3 — Почему? У меня есть сторонняя либа, которая разрабатывается соседней командой. Я не хочу поднимать общий мавеновский репозиторий для них, но хочу получать правки по определенным тегам из VCS, чтобы получать нужный мне API.
4 — Я лично с такой проблемой не сталкивался, просто слышал стоны своих коллег :) Однако, я хочу написать свой сборочный шаг (не важно фазу или шаг ЖЦ), чтобы он был написан в виде программы, потому что компиляция сложная для этого проекта. Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
5 — Ага, и что вы использовали из мавеновского арсенала? Вангую, что Ant :)
Адепты тех или иных инструментов есть всегда. Если инструмент может порешать мою боль, я им с радостью воспользуюсь. Мавен тем не менее крут своим репозиторием, тут этого не отнять…
Про проект с 100+ модулей — я открыл корневой помник… 1700 строк… Интересно (без сарказма), как будет выглядеть градловский скрипт сборки.
P.S. я с мавеном жил много много лет, готовить я его умею, но прогресс же не стоит на месте.
Вот я же говорю, что вы фразу из контекста выдрали. Я не говорил про долю рынка мавена, а говорил только о наборе функционала и гибкости, и в этом сравнении мавен очевидно проигрывает и, как я выразился, «остается не у дел».
P.S. я к вам в карму не лез, такой ерундой не занимаюсь.
Ну давайте возьмем несколько первых ссылок в гугле, например dzone.com/articles/gradle-vs-maven
Сравните объем файлов декларативного мавена и процедурного градла по простейшему билду.
Ну все еще впереди :) Могу описать свои проблемы:
1) Жесткая структура убивает многомодульные проекты со сложной иерархией.
2) Документация в многомодульных проектах генерируется отвратно и слабо настраивается (отчеты checkstyle, PMD, javadoc)
3) Нельзя положить исходники соседнего проекта и организовать билд-цепочку (при изменении в одном модуле ребилдить другой)
4) Нельзя настроить жизненный цикл по своему усмотрению
5) Если надо настроить сложный билд для нескольких языков, приходится юзать Ant с запуском настоящих билд скриптов :)
В моем случае речь не о новичках и сложности при анализе билд-скриптов, а сугубо инженерные проблемы. Хотя если опять же проект достаточно сложный, то читать и анализировать помник на пару тысяч строк, тоже то еще удовольствие…
Так не интересно, никаких аргументов с вашей стороны нет :(
Приведите, если не трудно, преимущества или недостатки одного над другим.
«Гибкость» в вашем твите это скорее преимущество градла, чем недостаток. Гибкость позволяет сделать то же самое, но с заделом под изменяющиеся условия.
Мне действительно интересно, потому что сталкивался не раз с адептами, которые с пеной у рта доказывают, что лучше мавена ничего нет и не было, и тащат его во все проекты. При этом какой-то внятной позиции добиться не удалось…
Вы не подумайте, я не адепт градла, если завтра выйдет тулза MavGradle, которая будет лучше работать и лучше подходить моим задачам, я стремительно туда перейду. Ну по-моему просто мавен уже морально устарел по приведенным мной выше аргументам.
И всё хорошо, когда сам пишешь этот скрипт, но вот когда его пишет кто-то другой, а тебе надо кусочек поправить.
Так в этом все и дело… Gradle нашел золотую середину и поэтому Maven остается не у дел, как в свое время оставался не удел Ant. Мир меняется, концепция тоже, а мы (разработчики) как двигатели должны использовать самое лучшее что придумано.
Поэтому фраза про фломастеры мне показалось плохим аргументом в пользу мавена. Gradle объективно более удачный инструмент => на него следует переходить и, отдав должные почести, оставить уже мавен в покое.
Ну на мой взгляд, это как раз не аргумент.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке. Gradle предоставляет золотую середину между сложностью написания таких скриптов и автоматизированным выполнением рутинных задач.
Maven в свою очередь экстремально декларативен, и если не дай б*г надо что то сделать нестандартное (структура проекта, жизненный цикл сборки и т.п.), то мавен принесет много боли.
Опять же имхо, в 21 веке будущее за гибкостью.
Извините, но сразу видно, что вы разработчик без опыта.
Мне что бы эту задачу сделать понадобиться очень много времени. Надо собрать архитектуру, подключить все зависимости, написать документацию, найти UI плагины (DnD, Popup, Grid+(filter+paginator)), написать middleware.
Для всего этого уже давно используются boilerplates. Одной кнопкой разворачивается инфраструктура + архитектура рекомендуемая фреймворком.
Выбор плагинов и их написание это и есть работа разработчика.
… разработчик написав пару строчек — я решу бизнес задачу
Очередные утопические мечты… Я на своей памяти уже столько таких «мечателей» повстречал, что уже тошно становится видеть еще одного. НИКОГДА не будет продукта, в котором двумя кликами мышками / двумя строчками кода / и т.д. можно будет решить любую бизнес задачу. Гарантировано.
Я помню ваши публикации несколько лет назад, где говорилось, что еще не все потеряно, надо просто подождать. Ну вот и дождались…
Это технокуб, умнее не придумаешь! ;)
2 — А вот и есть. Пробовал в многомодульном проекте со сложной иерархией прикрутить site-pulgin в связке с Swagger. Не разрешимая проблема это перекрестные ссылки между модулями по REST API, javadoc и др. Мавен просто не дает таких опций. А если нет сквозной навигации, зачем тогда вообще делать такой плагин?
3 — Почему? У меня есть сторонняя либа, которая разрабатывается соседней командой. Я не хочу поднимать общий мавеновский репозиторий для них, но хочу получать правки по определенным тегам из VCS, чтобы получать нужный мне API.
4 — Я лично с такой проблемой не сталкивался, просто слышал стоны своих коллег :) Однако, я хочу написать свой сборочный шаг (не важно фазу или шаг ЖЦ), чтобы он был написан в виде программы, потому что компиляция сложная для этого проекта. Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
5 — Ага, и что вы использовали из мавеновского арсенала? Вангую, что Ant :)
Адепты тех или иных инструментов есть всегда. Если инструмент может порешать мою боль, я им с радостью воспользуюсь. Мавен тем не менее крут своим репозиторием, тут этого не отнять…
Про проект с 100+ модулей — я открыл корневой помник… 1700 строк… Интересно (без сарказма), как будет выглядеть градловский скрипт сборки.
P.S. я с мавеном жил много много лет, готовить я его умею, но прогресс же не стоит на месте.
P.S. я к вам в карму не лез, такой ерундой не занимаюсь.
Сравните объем файлов декларативного мавена и процедурного градла по простейшему билду.
1) Жесткая структура убивает многомодульные проекты со сложной иерархией.
2) Документация в многомодульных проектах генерируется отвратно и слабо настраивается (отчеты checkstyle, PMD, javadoc)
3) Нельзя положить исходники соседнего проекта и организовать билд-цепочку (при изменении в одном модуле ребилдить другой)
4) Нельзя настроить жизненный цикл по своему усмотрению
5) Если надо настроить сложный билд для нескольких языков, приходится юзать Ant с запуском настоящих билд скриптов :)
В моем случае речь не о новичках и сложности при анализе билд-скриптов, а сугубо инженерные проблемы. Хотя если опять же проект достаточно сложный, то читать и анализировать помник на пару тысяч строк, тоже то еще удовольствие…
Приведите, если не трудно, преимущества или недостатки одного над другим.
«Гибкость» в вашем твите это скорее преимущество градла, чем недостаток. Гибкость позволяет сделать то же самое, но с заделом под изменяющиеся условия.
Мне действительно интересно, потому что сталкивался не раз с адептами, которые с пеной у рта доказывают, что лучше мавена ничего нет и не было, и тащат его во все проекты. При этом какой-то внятной позиции добиться не удалось…
Вы не подумайте, я не адепт градла, если завтра выйдет тулза MavGradle, которая будет лучше работать и лучше подходить моим задачам, я стремительно туда перейду. Ну по-моему просто мавен уже морально устарел по приведенным мной выше аргументам.
Так в этом все и дело… Gradle нашел золотую середину и поэтому Maven остается не у дел, как в свое время оставался не удел Ant. Мир меняется, концепция тоже, а мы (разработчики) как двигатели должны использовать самое лучшее что придумано.
Поэтому фраза про фломастеры мне показалось плохим аргументом в пользу мавена. Gradle объективно более удачный инструмент => на него следует переходить и, отдав должные почести, оставить уже мавен в покое.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке. Gradle предоставляет золотую середину между сложностью написания таких скриптов и автоматизированным выполнением рутинных задач.
Maven в свою очередь экстремально декларативен, и если не дай б*г надо что то сделать нестандартное (структура проекта, жизненный цикл сборки и т.п.), то мавен принесет много боли.
Опять же имхо, в 21 веке будущее за гибкостью.
Прям по Фрейду и в тему :)
Нет.
Для всего этого уже давно используются boilerplates. Одной кнопкой разворачивается инфраструктура + архитектура рекомендуемая фреймворком.
Выбор плагинов и их написание это и есть работа разработчика.
Очередные утопические мечты… Я на своей памяти уже столько таких «мечателей» повстречал, что уже тошно становится видеть еще одного. НИКОГДА не будет продукта, в котором двумя кликами мышками / двумя строчками кода / и т.д. можно будет решить любую бизнес задачу. Гарантировано.