Преамбула
В своем блоге я уже выкладывал цикл статей посвященных Maven. Откровенно говоря, как любой профессиональный программист, я хотел их просто пере-использовать – скопировать в блог сообщества. Но все-таки за прошедшие два года какая-то информация устарела, какая-то наоборот актуализировалась, знания упорядочились, понимание выросло. Поэтому этот цикл статей можно воспринимать как издание второе, переработанное и дополненное.
С чего начинается Maven?
Если совсем коротко, то Maven начинается с pom.xml. POM означает Project Object Model и представляет собой файл описания проекта. Это не только описание сборки проекта, хотя и оно тоже, файл может содержать информацию о разработчиках, контрибьторах, системах контроля версий, issue tracking, описание зависимостей проекта и управления зависимостями, правила поставки проекта, описание системы создания различных отчетов и сайта проекта… Перечислять можно долго, но лучше обратиться к первоисточнику
Технологически Maven это система управления плагинами. Именно так, любое действие и любая операция в Maven – это конфигурация и запуск соответствующего плагина. Даже стандартные действия в стандартной конфигурации все-равно выполняются плагинами. Таким образом мы можем говорить о том, что POM – есть консолидированная в одном месте конфигурация множества плагинов.
Ну а совсем быстро начать поможет простая и незатейливая магическая команда
mvn archetype:generate -DgroupID=com.mycompany.app -DartefactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart
Про архетипы в Maven, как их использовать и как создавать свои я напишу отдельно.
Зачем, зачем это все?
Довольно сложно объяснить сейчас, почему автоматические системы сборки проектов есть Добро (именно так, с большой буквы). Более того, если внимательно посмотреть на параметры стандартного компилятора javac вообще можно сказать, что никакой проблемы нет – нужно просто правильно настроить окружение и руки должны расти из плеч. И в какой-то степени это будет правдой, но лишь отчасти.
Дьявол, как всегда, кроется в деталях – пока речь идет о индивидуальной разработке сборку проекта действительно можно проводить штатными средствами системы и JDK. И даже при командной разработке можно собирать проекты точно также, с одной лишь поправкой – при вводе нового человека в проект необходимо потратить некоторое количество времени на настройку окружения. Проблемы начинаются тогда, когда окружение начинается изменятся и проблем тем больше, чем больше разработчиков в проекте. А продолжаются проблемы тем, что в современной разработке необходимо запускать юнит-тесты, формировать отчеты, считать покрытие кода тестами, выполнять автоматический сбор метрик о качестве этого самого кода и так далее, и тому подобное. До появления автоматических систем сборки проектов большинство проблем удавалось решить с помощью командных файлов. Командный файлы можно использовать и сегодня, но проект Apache Ant стал идейным продолжением парадигмы командных файлов.
В какой-то степени Ant это тоже набор плагинов, конфигурация которых описана в файле build.xml. Ant позволил существенно упростить и упорядочить сборку проектов. Его слабым местом стало отсутствие стандартного цикла сборки. Иными словами каждый новый проект начинается с определения стандартных properties (где лежат исходники, где лежат исходники тестов, куда складывать скомпилированные файлы), classpathes и стандартных действий – скомпилировать, протестировать, создать необходимые отчеты, упаковать. А проще говоря * либо с копирования файла сборки проекта из уже существующих, после чего отсечения лишнего и добавления нужного * либо организации наследования файлов сборки проектов, что для Ant задача не тривиальная, хотя и решаемая
Maven стал логичным развитием Ant и привнес в автоматическую сборку стандартизацию. Для Maven'а определена стандартная схема директорий (учитывая расположение исходников как проекта, так и тестов; единого места для скомпилированных и упакованных файлов; места для отчетов и результатов работы тестов и т.д.) и стандартный цикл сборки проекта. Таким образом рутинные операции больше делать не нужно. Разумеется любая стандартизация есть ограничения и выполнить нестандартную операцию стало сложнее, но по прежнему возможно.
Про основные отличия Ant и Maven я тоже как-нибудь напишу отдельно.
Что дальше?
Следующей статьей я планирую описать самый интересный и полезный на мой взгляд плагин Maven – dependency. Лично я считаю, то только ради этого плагина стоит изучать Maven и мигрировать на Maven. Даже если бы больше Maven от Ant ничем не отличался.
