Pull to refresh

Comments 56

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

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

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

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

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

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

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

Кто-нибудь может посоветовать хорошую статью по использованию maven на русском языке?
По состоянию на 5 месяцев назад такой небыло, для своей конторы сам описание их модели проектов, FAQ и инструкции по настройке писал.
к сожалению и сейчас ситуация особо не изменилась…
Хорошая тема для нового поста.
А если бы не переход на Java-разработку, как по вашему, вы что-нибудь потеряли без знания о maven (статьи в вашем блоге пока не читал, может там есть ответ)?

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

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

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

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

Поправьте если я где то ошибся плиз.
Sign up to leave a comment.

Articles