06 мая 2016

Безалкогольное пиво, резиновые женщины и Maven без XML


Все написанное ниже не претендует на сколь-нибудь значимую долю объективности и является едва оформленным потоком сознания, коий  нашел выход в лоно этой уютной днявочки лишь через мое редкое импульсивное графоманство. Даже более - без прекрасных  выступлений Баруха, Антона и Жени, равно как и отличного доклада Саши и Кирилла ничего этого бы не написалось. Ребята, спасибо вам за вдохновение: если чо - ругать можете идти в комменты. 


Сейчас Maven не ругает только ленивый.
Хотя нет - даже ленивый ругает.

Если посмотреть внутрь всей этой критики, то по сути все сводится к 3-4 пунктам:
  1. XML
  2. Скачивает тысячи гигабайт зависимостей
  3. Невозможность написать что-то свое быстро, невозможность ad-hoc кастомизации сборки
  4. Принципы резолвинга зависимостей
     
Начнем с последнего - принципы резолвинга зависимостей - про это вот тут вот написал один очень неглупый Барух. Мне дополнить сюда нечего - maven не идеален, под это дело понаставили всяких костылей типа enforcer-plugin, в Gradle кстати тоже их есть (читать с момента про Fine-tuning the dependency resolution process) и думаю еще будет. Почему я так думаю?  Потому что проблема транзитивных зависимостей или попросту dependency hell просто так вот не решается - тут надо что-нибудь умное придумать с монадами, haskell-ом и страшной математикой.

Едем дальше, вверх по списку - невозможность написать что-то свое быстро, невозможность налету кастомизировать билд под свои нужды.
Ну тут, имхо, все очень  правильно и хорошо. Почему?
Потому что :
  1. 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.  
  2. Если вам нужно что-то кастомизировать для своего проекта, то для этого во всех инструментах сборки есть плагины. Отличне maven от gradle в том, что в случае с gradle вы можете написать плагин в коде самого проекта и подключить его. Ну или вынести в отдельный проект, как того требует maven.

    Плагины можно писать и там, и там.  Тестировать их тоже можно  и в maven, и в gradle, с той лишь разницей что в maven харнесс для тестирования плагинов внешне напоминает окаменевшее говно мамонта, а в gradle testkit пока еще не устаканился - его переколбашивают с каждым релизом, поэтому у меня вызывает ассоциации с ... не буду говорить с чем. Если же хочется очень быстро нагавнокодить скриптец в билд файле - то идите уже в пункт 3 данной части повествования.
  3. Волшебный Groovy и желание творить. Пфф.... ну что сказать, давайте сначала. Вы серьезно думаете, что все инженеры в вашей команде хорошо разбираются в том как устроена сборка их  проекта ? Нет, даже так - вы УВЕРЕНЫ что все инженеры в вашей команде хорошо разбираются в том как устроена сборка проекта ?  Подозреваю, что среди читателей моего уютненького найдутся и те кто ответит  положительно на оба вопроса. Но, en masse, это, по моим наблюдениям, не так.  По моим наблюдениям 3/4 девелоперов не вникают туда. Соответственно их кастомизации на времени сборки проекта и качестве его результата могут отразится вполне однозначно с совершенно неоднозначными последствиями и временем их устранения.  Проще говоря - иметь возможность говнокодить в файлах сборки должны компетентные люди. Вот тут еще один  неглупый  Барух  про это хорошо разложил. Некомпетентным там делать нечего, пусть идут и пишут плагины, еще лучше плагины с тестами. 
Ладно, задержались тут, давайте дальше - maven скачивает полинтернета.
Каждый раз когда я такое слышу у меня в голове начинает пищать модем 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.

Рецепт наступления счастья:
  1. Идем сюда, читаем статью http://www.infoq.com/news/2015/03/maven-polyglot 
  2. Ставим себе и на сервер CI версию Maven 3.3.1 и старше.
  3. Идем на гитхаб
    1. Если вы любите YAML, то идем сюда и можем увидеть там такое вот


      Ну а если заинлайнить плагины, то еще компактнее

    2. Если вам не надо YAML, а хочется чего-то еще - то вам вот сюда.
    3. Сравниваем с оргинальным  pom.xml, который приложен  у меня в проекте.
  4. Впендюриваем это все себе в проект живем дальше спокойно, с maven.
Вместо послесловия

Когда то давно, в 2006-2007 годах я работал в аутсорсинге и переходя с проекта на проект видел везде одно и тоже - файл build.xml и папочку /lib с заботливо сложенными бинарями внутри.

После того как я попал на проект с maven жить стало легче, стандартнее и веселее.
Maven по сравнению с Ant дал очень много - он дал стандарт и создал целую экосистему вокруг себя.