Maven — автоматизация сборки проекта

    Уже давно я слышал об инструменте для автоматизации сборки проекта — 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. в оригинальной статье присутствует еще небольшой опрос, к участию в котором, в большей части, приглашаются РНР разработчики, остальные же — по заинтересованости
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 56
    • +3
      Я теперь вообще не понимаю как я без него раньше обходился. «Взрослые» проекты пишутся только с maven'ом!
      • +1
        если проект совсем взрослый, которуму нужна полная мощь а не шаблонность мавна — то пишут на ANT+Ivy
        • 0
          Ivy? Опишите в двух словах.
          • 0
            Ты не из NC?
          • 0
            «Dependency manager»
            Ровно два слова.
            • +1
              Ясно. Прочитал ваш пост ниже. Теперь я не вижу чем «кунг-фу» анта круче «кунг-фу» мавена. Может быть я не сталкивался с совсем нестандартной сборкой, но я почувствовал большое облегчение при работе с мавеном, этого мне сильно не хватало. Может вы недостаточно времени уделили мавену?

              Вы приводите пример использования ant + ivy для спринга. Вы наверно знакомы с JBoss, насколько я знаю все их проекты собираются мавеном.
              • 0
                Вы наверное dkurilenko ответить хотели? Я с Ivy вообще не работал, просто знаю что это такое.
              • 0
                на вкус и цвет все фломастеры разные

                насчет jboss давно уже зарекался не пользоваться ничем их после (не импонирует их стиль напсания кода)
          • 0
            а смысл использовать два продукта, если можно один? Расскажите уж тогда чем это удобнее — думаю не мне одному будет интересно
            • 0
              Главная фича мавна — это dependency resolver. А остальное достигается за счет своих плагинов. Плагины не всегда работают как надо, а порой таких плагинов как надо нету вовсе (какой — нибудь супер кастом сборка или деплой хитрый на сотни машин со всякими прибабахами). Это обозначает что плагин надо писать самому (и часто писать самому — это значит опять делать вставке на анте либо Groovy).

              Что имеем мы анте: полная свобода движений, написание скриптов любой сложности, куча готового проверенного сборочного кода. Но в анте нам не хватает депенденси менеджмента — тут на помощь приходить IVY. IVY может работать легко с любыми репозиториями для мавна или любыми другими — так же позволяет делать транзитивные билд.

              Ну и в качестве пруф линка: скажем нельзя не согласиться что Spring большой проект (http://www.techcrunchit.com/2009/08/10/vmware-acquires-springsource/ 420 млн $) — он собирается ант + иви.
              • 0
                build.xml рано или поздно превращается в помойку, особенно в больших проектах. Maven лучше поскольку он сам задает жизненный цикл
                • 0
                  а кто сказал что все надо засовавать в один билд хмл?

                  допустим у меня билд.xml в каждом модуле -это пару строк с импортом
                • 0
                  Maven отлично интегрируется с Ant и из него можно запустить любую Ant-таску. Таким образом при использовании maven мы ничего не теряем, а только лишь приобретаем дополнительный функционал.
              • 0
                Ты не их NC?
                • 0
                  тпу, черт, я пьян…

                  Ты не из NC?
              • 0
                В чём конкретно мощь Ant+Ivy?
                • 0
                  я пробовал ivy и maven-ant-tasks, второй мне понравился больше из-за лучшей интеграфии с ориентированным на maven окружением
                • 0
                  Авторы linux kernel с тоской посмотрели на gmake и вздрогнули.
                • 0
                  Также, когда в репозиториях нет нужных специфичных зависимостей или они слишком старые, то можно развернуть свой репозиторий и закачивать в него, как свои зависимости, так и сторонние. Также он может выступать, как прокси к других репозиториям. Ищите программы: Nexus(интерфейс на ExtJS, кстати), Artifactory, Archiva.
                  • 0
                    О сколько нам открытий чудных!.. :)
                    Может лучше в Java перенести?
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        maven.apache.org/users/index.html — не?
                        По ньансам действительно документации нифина нет, но начть никаких проблем :)
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • +2
                            чтобы дошло — нужно садится и работать :)
                        • 0
                          Думаю это получится не простейшая статья а уже перевод документации с офф. сайта мавена. :)
                          • НЛО прилетело и опубликовало эту надпись здесь
                        • +3
                          Одна из ключевых фич Мавена — очень высокая настраиваемость. Например в жизненный цикл сборки можно добавить такие шаги как генерация вспомогательных исходников, прогонка разнообразных механизмов оценки качества кода, составление всевозможных отчетов (прохождение тестов, покрытие кода тестами, замеры времени, отчеты о потенциальных ошибках и проч.), сжатие всяких CSS и JS, сборку и отправку статистики сборки (простите за тавтологию ;) и много-много других действий… В общем сейчас трудно представить крупный Java-проект без Мавена :)
                          • 0
                            согласен. кк только мне это понадобится, в процессе изучения джавы, так сразу обо всем и отпишусь :)
                            • 0
                              По-моему, одна из ключевых фич мавена — простота в простых случаях. А вот высокая настраиваемость потенциально возможна, но весьма сложна.
                            • 0
                              Теорию сборок JAVA серверов LINE AGE осваивал на http://www.ibm.com/developerworks/ru/edu/j-mavenv2/section2.html
                              может кому полезно будет.
                              • 0
                                А чем maven лучше ant?
                                • +5
                                  Навскидку:
                                  1) Декларативное описание привил сборки.
                                  2) Умет сам разрешать зависимости, смена версий используемых библиотек выполняется сменой одного числа на другое в одном конфиге.
                                  3) Множество плагинов для решения множества типовых задач.
                                  4) Возможность многократного использования фрагментов конфигурации на разных, но схожих проектах.

                                • 0
                                  Кто-нибудь может посоветовать хорошую статью по использованию maven на русском языке?
                                  • +1
                                    По состоянию на 5 месяцев назад такой небыло, для своей конторы сам описание их модели проектов, FAQ и инструкции по настройке писал.
                                    • 0
                                      к сожалению и сейчас ситуация особо не изменилась…
                                      • 0
                                        Хорошая тема для нового поста.
                                    • 0
                                      Если речь идет о web разработке и maven, то могу посоветовать плагин по склейке-упакованию javascript.
                                      mojo.codehaus.org/javascript-maven-tools/javascript-maven-plugin/
                                    • 0
                                      А если бы не переход на Java-разработку, как по вашему, вы что-нибудь потеряли без знания о maven (статьи в вашем блоге пока не читал, может там есть ответ)?

                                      В том смысле, что на сколько оно удобно/полезно для неJAVA web-разработчика (с Ant'ом вроде разобрался немного)?
                                      • 0
                                        ну в отрыве от Java мавен бесполезен, а вот системы сборки — да, они вполне полезны и не только в джаве.

                                        Например удобно компресить JS, решать те же зависимости (а не чекаутить постоянно ZF для PHP проектов), сетапить или апдейтить структуру БД и пр.
                                        • 0
                                          насчет бесполезности вы мягко говоря не правы.
                                          К примеру я использую его для поддержки цикла разработки flex приложений.
                                          Достаточно удобным он оказался и для билда python + extJS приложения.

                                          Другое дело что большая часть стандартных фаз сборки и плагинов заточена под java разработку.
                                      • 0
                                        Maven подходит для любых целей, где нужны сборка: например, сбокра Firefox-расширений.
                                        • 0
                                          сборка*
                                          • 0
                                            нативный код им не собирают
                                          • 0
                                            Отлично! Давно искал статью на русском про Maven. Сам сейчас думаю, стоит ли шкурка выделки? Т.е. использовать Maven или Ant в проекте. Ant как мне кажется более стабилен, есть большое кол-во документации. С другой стороны, начинать новый проект и использовать старую технологию сборки как-то не очень хорошо. Все больше склоняюсь к Maven. Есть 2 книжки на англ. языке по Maven. Читаю на досуге.
                                            • 0
                                              Творчества автора не читал но осуждаю… (с) В смывсле maven не пользовался, так что сравнивать сложно
                                              Если уже статья опубликована в разделе вебразработки, то хотелось бы спросить — может ли ктото сравнить maven vs rake для НЕ Java разработки?
                                              Объясню что я имею ввиду. Для мавена и ant, как я понимаю очень просто прописываются типичные действия. Но если чтото надо делать не типичное, я так понимаю надо писать плагин?

                                              Фактически я говорю о императивный vs декларативный подход в сборке. Для для джавы и стандартных действий, ant / maven круты. Но после capistrano / rake заганять себя в рамки XML как то уже не тянет.
                                              • +1
                                                1. Для Maven очень много плагинов, и не только Java. Например, популярен среди Flex-разработчиков: при помощи одной команды можно развернуть и запустить шаблон Flex-приложения, даже качать SDK не надо.
                                                2. Maven 3 поддерживает Groovy для тех кто не хочет «загонять себя в рамки XML»
                                                3. XML в свою очередь имеет кучу плюсов, таких как поддержка IDE(необязательно помнить зависимости, их версии и т.п. — есть автокомплит) или устанавливает рамки для разработчиков.
                                                • 0
                                                  Ммм, большое спасибо за ответ! про кучу готовых плагинов я знал, но вот что есть поддержка груви это интересно. Думаю стоит покопаться с мавеном.
                                                • 0
                                                  Ant — просто выполняет набор инструкций, указанный в файле. Инструкции вида: скомпилять всё в папке, скопировать файл, выполнить юнит-тест и т.п. Явно императивный скрипт для сборки.
                                                  Maven управляет жизненным циклом приложения на основании своей модели. Он может создать модуль, подготовить файлы для IDE, скомпилировать, упаковать, протестировать и т.п. Если хочется изменить поведение на какой-то фазе ЖЦ надо писать плагин. Если хочется добавить свои, непривязанные к ЖЦ операции над проектом — надо писать плагин. Разделение сущностей: декларативная модель, императивные тулы для притворения её в жизнь. Второе разрабатывает гражданским населением не часто.
                                                  Что есть «рамки xml», не понял.
                                                  • 0
                                                    Можно чуть поподробней о
                                                    > Явно императивный скрипт для сборки.
                                                    Под императивным подходом в rake я подразумевал, что каждое задание, это фактически ф-цияя на языке Ruby со всем вытекающими. То есть парой строчек, я могу организовать цикл в задаче, условие, использовать богатый набор стандартных библотек.
                                                    Я так понимаю что в ант, с эти несколько сложней — если чтото не предусмотренно синтаксисом Ант, то решить это можно только написанием плугина?

                                                    Поправьте если я где то ошибся плиз.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.