Пользователь
0,0
рейтинг
5 декабря 2009 в 00:27

Разработка → 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. в оригинальной статье присутствует еще небольшой опрос, к участию в котором, в большей части, приглашаются РНР разработчики, остальные же — по заинтересованости
Aлексей Токарь @AlexeyTokar
карма
80,9
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (56)

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

            Вы приводите пример использования ant + ivy для спринга. Вы наверно знакомы с JBoss, насколько я знаю все их проекты собираются мавеном.
            • 0
              Вы наверное dkurilenko ответить хотели? Я с Ivy вообще не работал, просто знаю что это такое.
              • 0
                Да, промазал.
            • 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
            если NC — North California, то да
      • 0
        В чём конкретно мощь Ant+Ivy?
      • 0
        я пробовал ivy и maven-ant-tasks, второй мне понравился больше из-за лучшей интеграфии с ориентированным на maven окружением
    • 0
      Авторы linux kernel с тоской посмотрели на gmake и вздрогнули.
  • 0
    Также, когда в репозиториях нет нужных специфичных зависимостей или они слишком старые, то можно развернуть свой репозиторий и закачивать в него, как свои зависимости, так и сторонние. Также он может выступать, как прокси к других репозиториям. Ищите программы: Nexus(интерфейс на ExtJS, кстати), Artifactory, Archiva.
  • 0
    О сколько нам открытий чудных!.. :)
    Может лучше в Java перенести?
    • 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 со всем вытекающими. То есть парой строчек, я могу организовать цикл в задаче, условие, использовать богатый набор стандартных библотек.
        Я так понимаю что в ант, с эти несколько сложней — если чтото не предусмотренно синтаксисом Ант, то решить это можно только написанием плугина?

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

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