Безалкогольное пиво, резиновые женщины и 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, то идем сюда и можем увидеть там такое вот
   

   	modelVersion: 4.0.0
   	groupId: org.examples
   	artifactId: mvn-polyglot
   	version: 0.0.1-SNAPSHOT
   	name: 'YAML Maven Love'
   	dependencies:
   	- { groupId: junit, artifactId: junit, version: 4.12, scope: test }
   	build:
   	plugins:
   	- groupId: org.apache.maven.plugins
   	artifactId: maven-compiler-plugin
   	version: 3.3
   	configuration:
   	testTarget: 1.8
   	- groupId: org.apache.maven.plugins
   	artifactId: maven-surefire-plugin
   	version: 2.18

   view raw pom.yml hosted with ❤ by GitHub
   
   
   Ну а если заинлайнить плагины, то еще компактнее
   

   	modelVersion: 4.0.0
   	groupId: org.examples
   	artifactId: mvn-polyglot
   	version: 0.0.1-SNAPSHOT
   	name: 'YAML Maven Love'
   	dependencies:
   	- { groupId: junit, artifactId: junit, version: 4.12, scope: test }
   	build:
   	plugins:
   	- { groupId: org.apache.maven.plugins, artifactId: maven-compiler-plugin, version: 3.3, configuration: {testTarget: 1.8 }}
   	- { groupId: org.apache.maven.plugins, artifactId: maven-surefire-plugin, version: 2.18 }

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

Вместо послесловия

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

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