Все написанное ниже не претендует на сколь-нибудь значимую долю объективности и является едва оформленным потоком сознания, коий нашел выход в лоно этой уютной днявочки лишь через мое редкое импульсивное графоманство. Даже более - без прекрасных выступлений Баруха, Антона и Жени, равно как и отличного доклада Саши и Кирилла ничего этого бы не написалось. Ребята, спасибо вам за вдохновение: если чо - ругать можете идти в комменты.
Сейчас Maven не ругает только ленивый.
Хотя нет - даже ленивый ругает.
Если посмотреть внутрь всей этой критики, то по сути все сводится к 3-4 пунктам:
- XML
- Скачивает тысячи гигабайт зависимостей
- Невозможность написать что-то свое быстро, невозможность ad-hoc кастомизации сборки
- Принципы резолвинга зависимостей
Едем дальше, вверх по списку - невозможность написать что-то свое быстро, невозможность налету кастомизировать билд под свои нужды.
Ну тут, имхо, все очень правильно и хорошо. Почему?
Потому что :
- 99.95% Java проектов на этой планете относятся к категории bloody enteprise (кровавый ынтырпрайз), поставляя из себя стандартный JAR/WAR/EAR, который замечательно собирается maven уже много лет, запускается в Jetty, ставится в app server и далее по списку. Gradle это тоже все наверное умеет, иначе нафиг оно вообще надо.
Android приложения я сюда даже относить не буду - Google прописал gradle как официальный build tool для своей платформы и спорить с этим конечно можно ( а ведь до того как это было maven-ом и android собираали, дада) , но наверное не за чем.
К слову, оставшиеся 0.05% от общей численности Java проектов на планете я отношу к проектам с уникальной природой, которым позволительно как пользоваться и не maven/пользоваться gradle / вообще написать свой build tool типа bazel от Google. - Если вам нужно что-то кастомизировать для своего проекта, то для этого во всех инструментах сборки есть плагины. Отличне maven от gradle в том, что в случае с gradle вы можете написать плагин в коде самого проекта и подключить его. Ну или вынести в отдельный проект, как того требует maven.
Плагины можно писать и там, и там. Тестировать их тоже можно и в maven, и в gradle, с той лишь разницей что в maven харнесс для тестирования плагинов внешне напоминает окаменевшее говно мамонта, а в gradle testkit пока еще не устаканился - его переколбашивают с каждым релизом, поэтому у меня вызывает ассоциации с ... не буду говорить с чем. Если же хочется очень быстро нагавнокодить скриптец в билд файле - то идите уже в пункт 3 данной части повествования. - Волшебный Groovy и желание творить. Пфф.... ну что сказать, давайте сначала. Вы серьезно думаете, что все инженеры в вашей команде хорошо разбираются в том как устроена сборка их проекта ? Нет, даже так - вы УВЕРЕНЫ что все инженеры в вашей команде хорошо разбираются в том как устроена сборка проекта ? Подозреваю, что среди читателей моего уютненького найдутся и те кто ответит положительно на оба вопроса. Но, en masse, это, по моим наблюдениям, не так. По моим наблюдениям 3/4 девелоперов не вникают туда. Соответственно их кастомизации на времени сборки проекта и качестве его результата могут отразится вполне однозначно с совершенно неоднозначными последствиями и временем их устранения. Проще говоря - иметь возможность говнокодить в файлах сборки должны компетентные люди. Вот тут еще один неглупый Барух про это хорошо разложил. Некомпетентным там делать нечего, пусть идут и пишут плагины, еще лучше плагины с тестами.
Каждый раз когда я такое слышу у меня в голове начинает пищать модем 56К - да, я настолько стар, что помню когда они впервые появились, потому что до этого были 32К.
Я еще помню интернет по карточкам. (А еще выход Windows 95, оригинальные D-Track и Carmageddon. Какой же я старый.)
Короче - большинство из вас живет в странах с хорошим интернетом, maven и gradle кэшируют скачанные зависимости весьма неплохо, а при наличии в середине между вами и центровыми репозиторями прокладки в виде Nexus/Artifactory проблема как бы сводится минутам к 5 за которые вы успеете хотя бы один раз грязно обругать maven перед коллегами на кухне за чашкой кофе и пойдете себе дальше работать. Пустое это.
И вот мы добрались до вершины нашего тортика и вишенки на нем - XML.
 |
| Хипстеры при виде XML |
Обычно говорят, что в maven тонны xml от которых кровь из глаз.
Опять же - я довольно стар - ребята, тонны xml есть в других местах.
В банках, например, где люди разбираются в характеристиках производительности различных библиотек для парсинга xml, потому что им реально надо парсить гигабайтные файлы.
А xml файл на 2000 строчек - это не страшно, и пускать кровь тут нет повода. С этим можно жить и работать. Знаете почему ? Потому что у xml в maven есть схема !!! Которая не позволит вам далеко уйти, если вы косячите.
Второй довод против xml заключается в том что "это совершенно невозможно читать".
Тут все очень спорно и индивидуально, но так и быть, поведемся на этот довод.
Не нравится XML - ок, maven умеет не только XML.
Рецепт наступления счастья:
- Идем сюда, читаем статью http://www.infoq.com/news/2015/03/maven-polyglot
- Ставим себе и на сервер CI версию Maven 3.3.1 и старше.
- Идем на гитхаб
- Если вы любите YAML, то идем сюда и можем увидеть там такое вот
Ну а если заинлайнить плагины, то еще компактнее
- Если вам не надо YAML, а хочется чего-то еще - то вам вот сюда.
- Сравниваем с оргинальным pom.xml, который приложен у меня в проекте.
- Впендюриваем это все себе в проект живем дальше спокойно, с maven.
Когда то давно, в 2006-2007 годах я работал в аутсорсинге и переходя с проекта на проект видел везде одно и тоже - файл build.xml и папочку /lib с заботливо сложенными бинарями внутри.
После того как я попал на проект с maven жить стало легче, стандартнее и веселее.
Maven по сравнению с Ant дал очень много - он дал стандарт и создал целую экосистему вокруг себя.
Комментариев нет:
Отправить комментарий