Уже целых две недели лежит в черновиках план данной статьи. Все никак нет времени сесть и написать хоть немного по каждому пункту. Но вот, вроде бы, выдалось несколько свободных минут — на эту запись и потрачу…
Уже давно я слышал об инструменте для автоматизации сборки проекта — 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, который может содежать блок 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. А еще я нашел великолепный плагин для WordPress, который позволяет вставлять голосования в посты — WP-Polls. Так что поспешу его испытать в действии и получить от вас исформацию по следующему вопросу:
почему же нету варианта использую maven c php?
не представляю как их совместно использовать. насколько я понял — мавен заточен под работу с java
http://www.php-maven.org ;)
Там фактически прописываешь другой конфиг и уже «заточен под php».
с нуля PHP приложения не разрабатываю, все на базе Drupal. поэтому и не использую.