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

[@Timmmm]

Я теперь вообще не понимаю как я без него раньше обходился. «Взрослые» проекты пишутся только с maven'ом!

[@dkurilenko]

если проект совсем взрослый, которуму нужна полная мощь а не шаблонность мавна — то пишут на ANT+Ivy

[@Timmmm]

Ivy? Опишите в двух словах.

[@rachiu]

Ты не из NC?

[@rachiu]

Не туда.

[@licvidator]

«Dependency manager»
Ровно два слова.

[@Timmmm]

Ясно. Прочитал ваш пост ниже. Теперь я не вижу чем «кунг-фу» анта круче «кунг-фу» мавена. Может быть я не сталкивался с совсем нестандартной сборкой, но я почувствовал большое облегчение при работе с мавеном, этого мне сильно не хватало. Может вы недостаточно времени уделили мавену?

Вы приводите пример использования ant + ivy для спринга. Вы наверно знакомы с JBoss, насколько я знаю все их проекты собираются мавеном.

[@licvidator]

Вы наверное dkurilenko ответить хотели? Я с Ivy вообще не работал, просто знаю что это такое.

[@Timmmm]

Да, промазал.

[@dkurilenko]

на вкус и цвет все фломастеры разные

насчет jboss давно уже зарекался не пользоваться ничем их после (не импонирует их стиль напсания кода)

[@AlexeyTokar]

а смысл использовать два продукта, если можно один? Расскажите уж тогда чем это удобнее — думаю не мне одному будет интересно

[@dkurilenko]

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

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

Ну и в качестве пруф линка: скажем нельзя не согласиться что Spring большой проект (http://www.techcrunchit.com/2009/08/10/vmware-acquires-springsource/ 420 млн $) — он собирается ант + иви.

[@maxcom]

build.xml рано или поздно превращается в помойку, особенно в больших проектах. Maven лучше поскольку он сам задает жизненный цикл

[@dkurilenko]

а кто сказал что все надо засовавать в один билд хмл?

допустим у меня билд.xml в каждом модуле -это пару строк с импортом

[@ItGold]

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

[@rachiu]

Ты не их NC?

[@rachiu]

тпу, черт, я пьян…

Ты не из NC?

[@dkurilenko]

если NC — North California, то да

[@Scala]

В чём конкретно мощь Ant+Ivy?

[@maxcom]

я пробовал ivy и maven-ant-tasks, второй мне понравился больше из-за лучшей интеграфии с ориентированным на maven окружением

[@jetman]

Также, когда в репозиториях нет нужных специфичных зависимостей или они слишком старые, то можно развернуть свой репозиторий и закачивать в него, как свои зависимости, так и сторонние. Также он может выступать, как прокси к других репозиториям. Ищите программы: Nexus(интерфейс на ExtJS, кстати), Artifactory, Archiva.

[@CheatEx]

О сколько нам открытий чудных!.. :)
Может лучше в Java перенести?

[@AlexeyTokar]

для Java это слишком примитивно, а веб-разработку это все же местами затрагивает :)

[@AlexeyTokar]

вообще статья написана в цикле "Миграция с PHP на Java"

[@CheatEx]

maven.apache.org/users/index.html — не?
По ньансам действительно документации нифина нет, но начть никаких проблем :)

[@kmpavloff]

чтобы дошло — нужно садится и работать :)

[@kmpavloff]

Думаю это получится не простейшая статья а уже перевод документации с офф. сайта мавена. :)

[@Regis]

Одна из ключевых фич Мавена — очень высокая настраиваемость. Например в жизненный цикл сборки можно добавить такие шаги как генерация вспомогательных исходников, прогонка разнообразных механизмов оценки качества кода, составление всевозможных отчетов (прохождение тестов, покрытие кода тестами, замеры времени, отчеты о потенциальных ошибках и проч.), сжатие всяких CSS и JS, сборку и отправку статистики сборки (простите за тавтологию ;) и много-много других действий… В общем сейчас трудно представить крупный Java-проект без Мавена :)

[@AlexeyTokar]

согласен. кк только мне это понадобится, в процессе изучения джавы, так сразу обо всем и отпишусь :)

[@romik]

По-моему, одна из ключевых фич мавена — простота в простых случаях. А вот высокая настраиваемость потенциально возможна, но весьма сложна.

[@advix]

Теорию сборок JAVA серверов LINE AGE осваивал на http://www.ibm.com/developerworks/ru/edu/j-mavenv2/section2.html
может кому полезно будет.

[@Ermak]

А чем maven лучше ant?

[@Regis]

Навскидку:
1) Декларативное описание привил сборки.
2) Умет сам разрешать зависимости, смена версий используемых библиотек выполняется сменой одного числа на другое в одном конфиге.
3) Множество плагинов для решения множества типовых задач.
4) Возможность многократного использования фрагментов конфигурации на разных, но схожих проектах.

[@Orion]

Кто-нибудь может посоветовать хорошую статью по использованию maven на русском языке?

[@CheatEx]

По состоянию на 5 месяцев назад такой небыло, для своей конторы сам описание их модели проектов, FAQ и инструкции по настройке писал.

[@AlexeyTokar]

к сожалению и сейчас ситуация особо не изменилась…

[@Orion]

Хорошая тема для нового поста.

[@kirsyc]

Если речь идет о web разработке и maven, то могу посоветовать плагин по склейке-упакованию javascript.
mojo.codehaus.org/javascript-maven-tools/javascript-maven-plugin/

[@maxcom]

еще вот такая штука есть — alchim.sourceforge.net/yuicompressor-maven-plugin/

[@Vii]

А если бы не переход на Java-разработку, как по вашему, вы что-нибудь потеряли без знания о maven (статьи в вашем блоге пока не читал, может там есть ответ)?

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

[@AlexeyTokar]

ну в отрыве от Java мавен бесполезен, а вот системы сборки — да, они вполне полезны и не только в джаве.

Например удобно компресить JS, решать те же зависимости (а не чекаутить постоянно ZF для PHP проектов), сетапить или апдейтить структуру БД и пр.

[@kivsiak]

насчет бесполезности вы мягко говоря не правы.
К примеру я использую его для поддержки цикла разработки flex приложений.
Достаточно удобным он оказался и для билда python + extJS приложения.

Другое дело что большая часть стандартных фаз сборки и плагинов заточена под java разработку.

[@maxcom]

нативный код им не собирают

[@webus]

Отлично! Давно искал статью на русском про Maven. Сам сейчас думаю, стоит ли шкурка выделки? Т.е. использовать Maven или Ant в проекте. Ant как мне кажется более стабилен, есть большое кол-во документации. С другой стороны, начинать новый проект и использовать старую технологию сборки как-то не очень хорошо. Все больше склоняюсь к Maven. Есть 2 книжки на англ. языке по Maven. Читаю на досуге.

[@Tonik]

Творчества автора не читал но осуждаю… (с) В смывсле maven не пользовался, так что сравнивать сложно
Если уже статья опубликована в разделе вебразработки, то хотелось бы спросить — может ли ктото сравнить maven vs rake для НЕ Java разработки?
Объясню что я имею ввиду. Для мавена и ant, как я понимаю очень просто прописываются типичные действия. Но если чтото надо делать не типичное, я так понимаю надо писать плагин?

Фактически я говорю о императивный vs декларативный подход в сборке. Для для джавы и стандартных действий, ant / maven круты. Но после capistrano / rake заганять себя в рамки XML как то уже не тянет.

[@Scala]

1. Для Maven очень много плагинов, и не только Java. Например, популярен среди Flex-разработчиков: при помощи одной команды можно развернуть и запустить шаблон Flex-приложения, даже качать SDK не надо.
2. Maven 3 поддерживает Groovy для тех кто не хочет «загонять себя в рамки XML»
3. XML в свою очередь имеет кучу плюсов, таких как поддержка IDE(необязательно помнить зависимости, их версии и т.п. — есть автокомплит) или устанавливает рамки для разработчиков.

[@Tonik]

Ммм, большое спасибо за ответ! про кучу готовых плагинов я знал, но вот что есть поддержка груви это интересно. Думаю стоит покопаться с мавеном.

[@CheatEx]

Ant — просто выполняет набор инструкций, указанный в файле. Инструкции вида: скомпилять всё в папке, скопировать файл, выполнить юнит-тест и т.п. Явно императивный скрипт для сборки.
Maven управляет жизненным циклом приложения на основании своей модели. Он может создать модуль, подготовить файлы для IDE, скомпилировать, упаковать, протестировать и т.п. Если хочется изменить поведение на какой-то фазе ЖЦ надо писать плагин. Если хочется добавить свои, непривязанные к ЖЦ операции над проектом — надо писать плагин. Разделение сущностей: декларативная модель, императивные тулы для притворения её в жизнь. Второе разрабатывает гражданским населением не часто.
Что есть «рамки xml», не понял.

[@Tonik]

Можно чуть поподробней о
> Явно императивный скрипт для сборки.
Под императивным подходом в rake я подразумевал, что каждое задание, это фактически ф-цияя на языке Ruby со всем вытекающими. То есть парой строчек, я могу организовать цикл в задаче, условие, использовать богатый набор стандартных библотек.
Я так понимаю что в ант, с эти несколько сложней — если чтото не предусмотренно синтаксисом Ант, то решить это можно только написанием плугина?

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