Уже давно я слышал об инструменте для автоматизации сборки проекта — Ant, но как-то не мог найти ему реального применения в проектах на PHP. Компилить вроде ничего не надо, внешние библиотеки вполне можно подключить через svn:externals, оставались только тесты, которые свободно выполнялись через $ phpunit AllTests.php, да перенос изменений на рабочий сервер (svn export + небольшой самописный скрипт). Даже достаточно хорошая статья об использовании ant в eclipse не подвигла меня на использование сего инструмента, да еще и build файлы писать не хотелось…

Вобщем все как всегда. Какая-то подобная штука вроде бы и не помешала бы, но все и так хорошо работало и лень было изучать псевдопомогающую технологию. Так было до тех пор, пока я не познакомился с Java…


С приходом джавы в мою жизнь, взгляд на вопрос использовать или нет автоматический билдер отпала сама собой — использовать. Ведь какой фрик будет вручную компилировать все файлы по всем директориям проекта и копировать их для деплоя в каталог контейнера сервлетов? Только очень терпеливый и не ленивый человек. Но лень двигатель прогресса и я начал читать про… maven.

Даже не знаю как он мне подвернулся. Вероятно после одного из запросов в гугл в процессе обучениям основ tomcat'а я получил знания о существовании этой программы. Уже четвертый продукт от Apache, который мне понадобился на пути к развертыванию первого проекта на java.

Maven сочетает в себе возможности ант (билдить и копировать файлы, проводить тесты), но кроме этого он помогает решать зависимости библиотек проекта, имеет вполне формальный lifecycle, имеет множество плагинов и занимает все те же три символа в коммандной строке: mvn vs ant.

Жизненный цикл у мавена довольно ожидаемый:

  • validate — проверяет корректность метаинформации о проекте
  • compile — компилирует исходники
  • test — прогоняет тесты классов из предыдущего шага
  • package — упаковывает скомпилированые классы в удобноперемещаемый формат (jar или war, к примеру)
  • integration-test — отправляет упаковынные классы в среду интеграционного тестирования и прогоняет тесты
  • verify — проверяет корректность пакета и удовлетворение требованиям качества
  • install — загоняет пакет в локальный репозиторий, откуда он (пекат) будет доступен для использования как зависимость в других проектах
  • deploy — отправляет пакет на удаленный production сервер, откуда другие разработчики его могут получить и использовать

При этом все шаги последовательны. И если, к примеру, выполнить $ mvn package, то фактически будут выполнены шаги: validate, compile, test и package. Таким образом использовать мавен довольно просто. Написали код, выполнили mvn test и можно работать дальше, убедившись что код не содержит синтаксических и логических ошибок.

Отдельно стоит упомянуть о зависимостях. Maven конфигурируется файлом pom.xml, который может содежать блок <dependencies />. В нем описывается какие библиотеки нужны проекту для полноценного функционирования. На шаге validate мавен проверяет удовлетворены ли зависимости и если нет, то скачивает из удаленный репозиториев необходимые компоненты в репозиторий локальный. Так, если 10 проектов зависят от одной и той же библиотеки SomeSpecificOrm, то нам больше не надо подключать ее в 10 местах через svn:external, особенно, если библиотека занимает достаточно места, а достаточно указать ее в файле зависимостей и она будет браться из локального репозитория мавена. При указании зависимостей можно указывать не только имя библиотеки, но и ее версию — таким образом не возникнет проблем с обратной совместимостью.

А теперь подойдем непосредственно к вопросу «чем мавен помогает в веб-разработке». Помимо компилирования, тестирования и пакетирования, мавен позволяет делать деплой проекта в tomcat посредством плагина tomcat-maven-plugin. Конфигурируется он в pom.xml и имеет приблизительно слудеющий вид:

[...]
<plugins>
    <plugin>
    	<groupid>org.codehaus.mojo</groupid>
    	<artifactid>tomcat-maven-plugin</artifactid>
    	<version>1.0-beta-1</version>
    	<configuration>
    	    <path>/</path>
    	    <url>http://site.local:8080/manager</url>
    	    <server>site.local</server>
    	</configuration>
    </plugin>
</plugins>
[...]

Конфигурация требует небольшого пояснения. Так path отвечает за путь на который будет развернут сервлет. Так как мы разворачиваем полноценное самодостаточное веб-приложение, то разворачивать будем в /. Url указывает на путь к менеджеру хоста, через который будем проводить деплой. Сервлет менеджера создается обычно во время создания нового виртуального хоста. Server указывает id сервера. Тут нужно еще более углубиться в объяснения…

Так как для деплоймента через хост менеджер нужно пройти авторизацию, а указывать данные для логина в файле конфигурации не самое правильное решение, так как от сервера к серверу данные могут изменяться, поэтому используется указатель по id. Сами же данне авторизации конфигурируются в файле ~/.m2/settings.xml в секции servers. Так у меня эта секция выглядит следующим образом:

[...]
<servers>
    <server>
        <id>site.local</id>
        <username>manager</username>
        <password>manager</password>
    </server>
</servers>
[...]

username и password должны соответствовать пользователю с правами manager из файла tomcat-users.xml(подробнее в предыдущей статье о сервлетах).

Теперь чтобы проект отправить в контейнер сервлетов, достаточно выполнить: $ mvn tomcat:deploy и мавен сам позаботится о компилировании, тестировании, пакетировании и деплойменте проекта. Останется только обновиться страницу браузера, чтобы увидеть изменения.

Да. Напоследок хочу сказать, что мавен так же диктует свою иерархию директорий, но чтобы не создавать её вручную, достаточно выполнить:

$ mvn archetype:create \
  -DarchetypeGroupId=org.apache.maven.archetypes \
  -DgroupId=com.mycompany.app \
  -DartifactId=my-app

А для eclipse есть специальный плагин, который упростит создание и сопровожение проекта.

P.S.Понимаю, что материал раскрыл не полностью, так что если какие-то моменты остались совсем неясными или просто не полными — пишите, а я буду статью дополнять.

P.P.S. в оригинальной статье присутствует еще небольшой опрос, к участию в котором, в большей части, приглашаются РНР разработчики, остальные же — по заинтересованости