В этой статье я не буду развивать очередной холивар на тему, что круче. Скорее, будет проведен сравнительный обзор, опираясь на точку зрения самого Apache* и личного опыта нашей команды Build Factory. Обращаю внимание, что речь идет о большом Enterprise. Это означает, что в учет не берутся юзкейсы, когда вчера решили — сегодня уже должно быть сделано. Зато в учет берутся очень большие размеры проекта, распределенные по всему миру команды разработчиков и прочие прелести.
Очень часто можно услышать мнение, что Ant сам по себе с Maven сравнивать нельзя. А вот Ant + Ivy уже может составить конкуренцию Maven. Отчасти это правда.
* Написал сие, ибо помню, где-то сами Apache говорили, что пришло время Maven, старайтесь отходить от Ant. Но так и не смог найти искомое.
Увы, всем известно, что в большинстве компаний/проектов таким аспектом, как Build Management, занимаются сами разработчики. Потому и мнение разработчиков на эту тему в интернетах доминирует. Я читал множество статей с детальным анализом всех плюсов и минусов использования обеих систем, и становилось печально. Основная преследуемая цель этих статей была — скомпилировать код. Ну иногда еще сделать архив, инсталляцию, и залить это все куда-то на фтп или задеплоить на Tomcat. Удобное управление зависимостями, естественно, весьма удобная фича, потому берется в расчет. И все. И потом Ant + Ivy начинают сравнивать с Maven.
Для многих, наверное, станет неожиданностью, что кроме DEV и QA есть еще TL, PM, PO, PSO, Support, CPE, L10N, Installation, дизайнеры, и много других мест, откуда приходит контент, который тоже должен стать частью дистрибутива продукта. Исходя из этого открытия, становится понятно, что оставлять власть над процессом у DEV не есть… эффективно. Потому в больших проектах и есть отдельные команды Build Factory. Но это уже тема совсем для другой истории.
Возвращаясь же к нашей теме, мы пришли к самому главному тезису этой статьи. Ant — это просто Build Tool, Maven — это уже Project Management Tool.
Отлично, теперь, отталкиваясь от этого тезиса, мы будем сравнивать две системы уже совершенно по другому.
Я очень часто видел, как людей пытаются научить пользоваться Maven, объясняя на примере Ant. Т.е. показывают, как делать вещи, которые все привыкли делать Ant'ом, в Maven. И показывают это на примере сравнения build.xml и pom.xml.
Но сравнивать эти два файла в корне не правильно.
Wiki:
Maven, в отличие от другого сборщика проектов Apache Ant, обеспечивает декларативную, а не императивную сборку проекта.
Другими словами, в build.xml мы описываем наши таргеты, последовательно объявляя другие таргеты, что очень похоже на последовательное выполнение команд. Процесс написания build.xml есть ни что иное, как написание скрипта сборки. Одни таргеты мы объединяем в другие, что создает подобие вызова функций, правда не явно — а через иерархию зависимостей. Мы полностью дизайним весь процесс сборки.
В pom.xml у нас нет такой свободы. На самом деле, Maven уже заранее знает, что делать с вашим проектом, если этот проект имеет соответствующую структуру. В pom.xml мы просто описываем проект — это засереализованная в XML информация. И для успешного использования Maven, получается, нам нужно понимать все эти lifecycles, phases и прочие вещи. Нам нужно выучить, что же Maven от нас требует и как он работает, и описать наш проект в pom.xml. В этом обычно и кроется проблема. Обычно в DEV командах подобное «ограничение свободы» воспринимается крайне негативно. Вместо того, что бы задизайнить свою фичу, приходится вникать в то, как работает чужой код, загонять себя в рамки этих ограничений, ну и так далее. Зачем?
Ну, во первых, ограничение свободы само по себе не так уж и плохо. Развивая эту тему, мы можем скатиться до холивара Assembler VS Java, но мы этого делать не будем. Мы просто вспомним, как часто мы видим .classpath и файлы IDE в SCM. Как трудно порой разобраться в этом хитросплетении инклудов build.xml, как трудно это дебажить. Как трудно понять, какой из модулей собирается раньше, и почему этот jar не попал в war. А когда одни только сорцы весят ~3Gb, мы будем тратить наши человекочасы на оптимизацию процесса сборки. Мы будем тратить их так-же на дизайн солюшна, когда наши менеджеры придумают новую интеграцию с другим продуктом, когда изменят принципы локализации или доставки сервис-паков. Вообщем, много головной боли.
А теперь постарайтесь воспринять то, что навязывает нам Maven, не как ограничение свободы, а как некую стандартизацию. Оглянитесь, используя Maven, мы можем интегрироваться в CI System, в SCM, в Issue tracker, Backlog, метрики, да куда угодно. Можем делать релиз продукта одной кнопкой. Ведь все это стало возможным именно благодаря этой стандартизации (конечно, это возможно сделать и с Ant, но какой ценой?). А процесс оптимизации процесса сборки теперь в 90% случаев — это разделение одного модуля на несколько более мелких, которые могут собираться параллельно. Интеграция с другими участниками development process тоже заметно упростилась и стала прозрачной — у каждой команды может быть свой Maven репозиторий (либо один общий корпоративный), и мы лишь по решению топ-менеджеров меняем версии артефактов в pom.xml.
Почему-же, в таком случае, спросите вы, все еще так много говорят об Ant? Как я уже сказал в названии статьи — давайте жить дружно. Давайте просто осознаем, что Ant и Maven прежде всего совершенно разные инструменты. Если у вас простой маленький проект, и нет сильного Project Management'а — вам, верноятно, можно обойтись без Maven. Тем более, если вы с ним не знакомы — ведь вам придется потратить время на изучение. Кроме того, большие монструозные продукты, как правило, очень медлительны и неповоротливы. Именно по этой причине многие из них до сих пор используют Ant. Возможно, менеджеры не видят необходимости мигрировать на Maven, а возможно это legacy продукт (или его версия), который просто поддерживается, и не более. Потому Ant будет востребован и никуда не денется. Но если вы уже знаете, как использовать Maven — используйте его. Это поможет вам потом в будущем не встать на грабли. Все-таки Java и Ant — это в принципе одно и то-же поколение, а Maven создавался значительно позже — вобрав в себя весь накопленный опыт прошедших лет.
Полезные ссылки:
Ivy сравнивает себя с Maven: ant.apache.org/ivy/m2comparison.html
Сравнение от codehaus: docs.codehaus.org/display/MAVEN/Feature+Comparisons
Еще одна интересная точка зрения: xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html
Автор: LLIbIcpEP
