В течение последних двух лет я использовал Maven как инструмент для сборки проектов. В результате я остался весьма недоволен Мавеном, недоволен настолько, что всерьез обдумываю перевод нынешнего проекта на Ant.
Прежде, чем обсуждать причины моего недовольства, нужно сказать пару слов о Мавене. Я не буду его подробно описывать, просто кратко изложу его основные особенности.
Описание на сайте гласит, что Мавен — это инструмент для управления программными проектами (software project management tool). В реальности Мавен — это система для управления сборкой проекта, по целям во многом схожая с инструментами типа Ant и make. Отличительные особенности Мавена таковы:
Как видно, в теории Мавен — очень мощный и интересный инструмент. На практике же картина выглядит несколько по-иному. Безусловно, у Мавена есть определенные достоинства, но также, увы, и много весьма ощутимых недостатков.
Начнем с достоинств. Сборка при помощи Мавена происходит очень просто. Достаточно в корне проекта написать mvn clean install — и проект соберется! Не надо заниматься поиском и скачиванием нужных библиотек, не надо изучать скрипты. Эта команда будет работать всегда, вне зависимости от типа проекта.
Кроме того, поскольку Мавен очень способствует стандартизации структуры директорий (читай: крайне затрудняет работу с нестандартной структурой), всегда довольно легко понять где что находится.
Поскольку проект описывается именно в виде модели, становятся возможными некоторые интересные вещи. Например, можно из проекта Мавена автоматически создать проект для, например, Эклипса — при этом в Эклипсовском проекте уже будут правильно настроены все директории, подключены библиотеки и так далее.
На этом список достоинств заканчивается. Переходим к недостаткам.
Мавен плохо документирован. Документация вроде как есть, но найти ответ на многие вопросы практически невозможно. Это касается как самого Мавена, так и его плагинов. Более того, даже книга «Maven: the definitive guide», хотя и проясняет многие вещи, но оставляет очень много вопросов открытыми.
Мавен болтлив, но вместе с тем невразумителен. В стандартном режиме он выводит во время сборки огромное количество всевозможной информации, как правило совершенно ненужной. Отладочный режим — это просто катастрофа! На нашем проекте в этом режиме Мавен при сборке выводил более 80 тысяч строк! При этом сообщения об ошибках и проблемах зачастую крайне туманны и загадочны.
Модели проекта длинны, плохо читаемы и трудно изменяемы. Муторный синтаксис на основе XML; наследование моделей, в результате чего зачастую приходится просматривать несколько моделей, чтобы определить, какая же конфигурация в конце концов будет использована при сборке; размазывание конфигурации по разным частям модели — вот далеко не полный перечень факторов, которые приводят к такой ситуации.
Процесс сборки зависит от внешних систем. Именно — от репозиториев. У меня был случай, когда у одного нового сотрудника возникли необъяснимые проблемы со сборкой проекта. В конце концов выяснилось, что у одного из репозиториев поменялся URL. Те, у кого Мавен уже успел скачать все что нужно, ничего не замечали; а вот новые сотрудники не могли собрать проект.
Мавен в процессе сборки скачивает огромное количество всевозможных файлов. Дело в том, что одним из элементов системы управления зависимостями Мавена является локальный репозиторий. Все, что оказывается нужным для сборки, Мавен скачивает и устанавливает в этот самый локальный репозиторий. С одной стороны, это хорошо — если какая-нибудь библиотека нужна в нескольких проектах, она будет скачана только один раз, а потом Мавен будет брать ее из этого самого местного репозитория. С другой стороны, количество скачанного поражает воображение. Например, на моем рабочем компьютере, на котором я собирал около пяти разных (но однотипных) проектов, репозиторий занимает больше гигабайта, и содержит четыре с половиной тысячи файлов и директорий!
Мавен плохо подходит для автоматизации «около-сборочных» задач. Мне часто в разных проектах встречались некоторые действия, зачастую не имеющие отношения к основной сборке, которые требовали автоматизации: скопировать файлы из одной части проекта в другую, обработать код анализаторами, почистить некоторые директории и так далее. Когда я пользовался Антом, я создавал дополнительные цели в проекте — и все было прекрасно (ну да, проект при этом усложнялся, но все было документировано). Мавен просто не дает такой возможности.
Очень жесткий подход Мавена в отношении последовательности сборки, создает большие трудности в тех случаях, когда нужно хотя бы на шаг от этой последовательности отойти. К примеру, мне в какой-то момент понадобилось дважды скомпилировать один и тот же модуль, но с разными настройками, и потом поместить два результата в разные места под разными именами. Это оказалось сделать очень и очень нетривиально.
Мавен труден для понимания и освоения. Причины — все вышеизложенное.
Особенности Мавена, по большей части, приносят больше проблем, чем пользы. Возможно, Мавен может быть хорош для проектов в стабильной фазе, когда изменений в структуре проекта уже почти не происходит. В активной фазе проекта, когда процесс сборки еще не сформировался полностью — добавляются новые модули, идет перемещение частей — Мавен превращается в бесконечный источник головной боли.
Я сам хочу отказаться от использования Мавена, и перейти на сочетание Ant + Ivy. Ant прекрасно справится со сборкой проекта, а Ivy добавит к нему возможность управления зависимостями, ту самую возможность Мавена, которой очень не хватало в других инструментах.
Прежде, чем обсуждать причины моего недовольства, нужно сказать пару слов о Мавене. Я не буду его подробно описывать, просто кратко изложу его основные особенности.
Что такое Мавен?
Описание на сайте гласит, что Мавен — это инструмент для управления программными проектами (software project management tool). В реальности Мавен — это система для управления сборкой проекта, по целям во многом схожая с инструментами типа Ant и make. Отличительные особенности Мавена таковы:
- Примат соглашений над конфигурацией (convention over configuration). Если проект следует некоторым стандартам, то Мавен сам поймет, что и как надо сделать, чтобы собрать проект. В описании проекта указывается только то, что отличается от стандарта (например, нестандартная структура директорий).
- Управление зависимостями (dependency management). Если для сборки (или для исполнения) проекта требуются некоторые дополнительные библиотеки, их достаточно указать в описании проекта — Мавен сам их скачает, разберется с тем, какая нужна версия, а если эти библиотеки, в свою очередь, зависят от других библиотек, то Мавен скачает и их, и так далее. Для этого Мавен использует удаленные хранилища (репозитории, repositories), в которых хранятся библиотеки и их описания.
- Описательный язык. В отличие от других аналогичных инструментов, Мавен использует именно описание проекта, которое называется Объектная Модель Проекта (Project Object Model), сокращенно POM (я буду в дальнейшем называть это «моделью проекта»). В модели не указывается, что, как и когда должно быть выполнено для сборки проекта; вместо этого там описывается то, как проект устроен, от чего он зависит и так далее. Предполагается, что Мавен самостоятельно разберется с тем, как на основании этой информации собрать проект.
- Жесткая схема последовательности сборки. Мавен предполагает, что сборки всех проектов укладываются в несколько типов последовательностей сборки (в терминологии Мавена «жизненных циклов», lifecycles). Последовательность состоит из определенных фаз (обработка ресурсов, компиляция, тесты, упаковка, установка...), которые проект проходит в жестко заданном порядке. В модели проекта указывается специфические детали того, что именно должно быть сделано в ту или иную фазу («при компиляции использовать вот такие опции компилятора...»).
Реальность
Как видно, в теории Мавен — очень мощный и интересный инструмент. На практике же картина выглядит несколько по-иному. Безусловно, у Мавена есть определенные достоинства, но также, увы, и много весьма ощутимых недостатков.
Начнем с достоинств. Сборка при помощи Мавена происходит очень просто. Достаточно в корне проекта написать mvn clean install — и проект соберется! Не надо заниматься поиском и скачиванием нужных библиотек, не надо изучать скрипты. Эта команда будет работать всегда, вне зависимости от типа проекта.
Кроме того, поскольку Мавен очень способствует стандартизации структуры директорий (читай: крайне затрудняет работу с нестандартной структурой), всегда довольно легко понять где что находится.
Поскольку проект описывается именно в виде модели, становятся возможными некоторые интересные вещи. Например, можно из проекта Мавена автоматически создать проект для, например, Эклипса — при этом в Эклипсовском проекте уже будут правильно настроены все директории, подключены библиотеки и так далее.
На этом список достоинств заканчивается. Переходим к недостаткам.
Мавен плохо документирован. Документация вроде как есть, но найти ответ на многие вопросы практически невозможно. Это касается как самого Мавена, так и его плагинов. Более того, даже книга «Maven: the definitive guide», хотя и проясняет многие вещи, но оставляет очень много вопросов открытыми.
Мавен болтлив, но вместе с тем невразумителен. В стандартном режиме он выводит во время сборки огромное количество всевозможной информации, как правило совершенно ненужной. Отладочный режим — это просто катастрофа! На нашем проекте в этом режиме Мавен при сборке выводил более 80 тысяч строк! При этом сообщения об ошибках и проблемах зачастую крайне туманны и загадочны.
Модели проекта длинны, плохо читаемы и трудно изменяемы. Муторный синтаксис на основе XML; наследование моделей, в результате чего зачастую приходится просматривать несколько моделей, чтобы определить, какая же конфигурация в конце концов будет использована при сборке; размазывание конфигурации по разным частям модели — вот далеко не полный перечень факторов, которые приводят к такой ситуации.
Процесс сборки зависит от внешних систем. Именно — от репозиториев. У меня был случай, когда у одного нового сотрудника возникли необъяснимые проблемы со сборкой проекта. В конце концов выяснилось, что у одного из репозиториев поменялся URL. Те, у кого Мавен уже успел скачать все что нужно, ничего не замечали; а вот новые сотрудники не могли собрать проект.
Мавен в процессе сборки скачивает огромное количество всевозможных файлов. Дело в том, что одним из элементов системы управления зависимостями Мавена является локальный репозиторий. Все, что оказывается нужным для сборки, Мавен скачивает и устанавливает в этот самый локальный репозиторий. С одной стороны, это хорошо — если какая-нибудь библиотека нужна в нескольких проектах, она будет скачана только один раз, а потом Мавен будет брать ее из этого самого местного репозитория. С другой стороны, количество скачанного поражает воображение. Например, на моем рабочем компьютере, на котором я собирал около пяти разных (но однотипных) проектов, репозиторий занимает больше гигабайта, и содержит четыре с половиной тысячи файлов и директорий!
Мавен плохо подходит для автоматизации «около-сборочных» задач. Мне часто в разных проектах встречались некоторые действия, зачастую не имеющие отношения к основной сборке, которые требовали автоматизации: скопировать файлы из одной части проекта в другую, обработать код анализаторами, почистить некоторые директории и так далее. Когда я пользовался Антом, я создавал дополнительные цели в проекте — и все было прекрасно (ну да, проект при этом усложнялся, но все было документировано). Мавен просто не дает такой возможности.
Очень жесткий подход Мавена в отношении последовательности сборки, создает большие трудности в тех случаях, когда нужно хотя бы на шаг от этой последовательности отойти. К примеру, мне в какой-то момент понадобилось дважды скомпилировать один и тот же модуль, но с разными настройками, и потом поместить два результата в разные места под разными именами. Это оказалось сделать очень и очень нетривиально.
Мавен труден для понимания и освоения. Причины — все вышеизложенное.
Выводы
Особенности Мавена, по большей части, приносят больше проблем, чем пользы. Возможно, Мавен может быть хорош для проектов в стабильной фазе, когда изменений в структуре проекта уже почти не происходит. В активной фазе проекта, когда процесс сборки еще не сформировался полностью — добавляются новые модули, идет перемещение частей — Мавен превращается в бесконечный источник головной боли.
Я сам хочу отказаться от использования Мавена, и перейти на сочетание Ant + Ivy. Ant прекрасно справится со сборкой проекта, а Ivy добавит к нему возможность управления зависимостями, ту самую возможность Мавена, которой очень не хватало в других инструментах.