Comments 35
Уделив изучению Maven тоже время что и на ant, собирать проекты вы будете намного быстрее. Ant по моему уже устарел.
Ant не устарел. Этот же Maven использует ant внутри себя. Просто ant для всеобщих задач. А вот для сборок проектов на Java и существует Maven. Лучше Maven в этом плане ничего нет и не будет. Но и Ant хоронить не надо.
Лучше Маven ничего не будет? o_0
Что одно (ant) что другое (maven) говно. Хороши для приложений уровня hello-world для более сложных проектов абсолютно не подходят. Java билд системы еще ждут своего будущего.
PS Рекомендую взглянуть на Rake, Buildr, sbt.
Что одно (ant) что другое (maven) говно. Хороши для приложений уровня hello-world для более сложных проектов абсолютно не подходят. Java билд системы еще ждут своего будущего.
PS Рекомендую взглянуть на Rake, Buildr, sbt.
Спорный вопрос. Особенно насчет времени. У мавена есть один довольно существенный недостаток. Библиотеки он берет из интеренета. Это кончено хорошо. Но:
1. Нужной библиотеки в доступных репозиториях может банально не быть.
2. Если Вам надо попатчить Jboss.seam.1.2.jar то патченную библиотеку надо где-то хранить (для всех 6 членов команды сидящих в 3 разных городах)
3. Если через 3 года вы сделаете checkout проекта из SVN у Вас нет 100% гарантии что все нужные библиотеки будут доступны, а если они будут доступны, что war который будет собран бует точно такой же функционал как тот который Вы собирали 3 года назад.
Все это конечно решаемо, но если Вам нужен 100% контроль над тем что получается в результате, сил приходится прикладывать заметно больше чем с ant.
1. Нужной библиотеки в доступных репозиториях может банально не быть.
2. Если Вам надо попатчить Jboss.seam.1.2.jar то патченную библиотеку надо где-то хранить (для всех 6 членов команды сидящих в 3 разных городах)
3. Если через 3 года вы сделаете checkout проекта из SVN у Вас нет 100% гарантии что все нужные библиотеки будут доступны, а если они будут доступны, что war который будет собран бует точно такой же функционал как тот который Вы собирали 3 года назад.
Все это конечно решаемо, но если Вам нужен 100% контроль над тем что получается в результате, сил приходится прикладывать заметно больше чем с ant.
1. Кроме базового репозитория есть альтернативные. За последние год-два не нашел только одну библиотеку по работе с json. Выбрал другую.
2. Интересно увидеть выход который предлагаете вы. Решение есть, поднять свой репозитарий и в нем хранить все что вам понадобиться.
3. Эта проблема организации разработки, мавен поддерживает версионность. Интересно как вас спасет ант в этом случае.
Я 100% контролирую результат который я получаю с Maven.
2. Интересно увидеть выход который предлагаете вы. Решение есть, поднять свой репозитарий и в нем хранить все что вам понадобиться.
3. Эта проблема организации разработки, мавен поддерживает версионность. Интересно как вас спасет ант в этом случае.
Я 100% контролирую результат который я получаю с Maven.
Я не сомневаюсь что у Вас все хорошо. Вопрос в том, сколько времени ушло на обучение, сколько тратится на поддержание состояния — «хорошо».
По поводу #2 — решение простое берется seam, правится и кладется в svn как и остальный библиотеки. Про свой репозиторий я в курсе, проблема в том, что никто не гарантирует наличия в нем правленного jar-а через пол года.
Еще раз мавен хорошо. Но правильно использовать его джуниору сложно. Фактически не реально. Ant вполне реально — проверено на живых джуниорах-добровольцах.
По поводу #2 — решение простое берется seam, правится и кладется в svn как и остальный библиотеки. Про свой репозиторий я в курсе, проблема в том, что никто не гарантирует наличия в нем правленного jar-а через пол года.
Еще раз мавен хорошо. Но правильно использовать его джуниору сложно. Фактически не реально. Ant вполне реально — проверено на живых джуниорах-добровольцах.
Не поверите, ушло около часа на чтение документации и первая сборка была готова. С начала немного непонятно как пользоваться плагинами, но со временем все становится на свои места.
Хммм странно, как это никто не гарантирует? Как тогда гарантировать его наличие в svn'е?
Возможно, Вы правы. После того как я пересел на maven вся сборка проходит в разы быстрее, можно даже сказать что за меня все делает maven.
Хммм странно, как это никто не гарантирует? Как тогда гарантировать его наличие в svn'е?
Возможно, Вы правы. После того как я пересел на maven вся сборка проходит в разы быстрее, можно даже сказать что за меня все делает maven.
ну если коротко maven vs ant:
Мавен более декларативный и что важно вл многом сам отслеживает зависимости артефактов. В этом его сила и слабость одновременно.
Ант, проще, нагляднее, более процедурный (для студента как правило идея не процедурной системы сборки вообще тяжела) и более стабильный.
Дело в том, что svn это понятно всем, все понимают как его бэкапить что с ним делать. Может взять код за архивировать, послать заказчику архив и сказать установи ant и скажи ant build.
С мавеном, особенно если у вас свой репозиторий такой трюк не проходит.
BTW мавен особенно любим индусами которые обожают строить инфраструктуру из 33 серверов и репозиториев.
Можно наверное сказать что мавен хорош для больших и длинных проектов в которых есть мега крутые девелоперы способные все настроить по уму.
Ant более всеяден.
Мавен более декларативный и что важно вл многом сам отслеживает зависимости артефактов. В этом его сила и слабость одновременно.
Ант, проще, нагляднее, более процедурный (для студента как правило идея не процедурной системы сборки вообще тяжела) и более стабильный.
Дело в том, что svn это понятно всем, все понимают как его бэкапить что с ним делать. Может взять код за архивировать, послать заказчику архив и сказать установи ant и скажи ant build.
С мавеном, особенно если у вас свой репозиторий такой трюк не проходит.
BTW мавен особенно любим индусами которые обожают строить инфраструктуру из 33 серверов и репозиториев.
Можно наверное сказать что мавен хорош для больших и длинных проектов в которых есть мега крутые девелоперы способные все настроить по уму.
Ant более всеяден.
Конкренто в моем случае Мавен очень удобен тем, что с ним не надо вкладывать кучу библиотек. У нас есть около 15 довольно схожих по структуре проектов, и почти все используют примерно одинаковый набор библиотек. Так вот передать разработчику в другой город все эти проекты стоит немалого времени (в провинциях интернеты не так быстры, как хоетлось бы), а с Мавеном все проекты из почти гига превращаются буквально в 10-15 Мб.
Плюс еще очень легко работать из разных IDE как с нативным для этой IDE проектом — для всех популярных сред есть плагины генерации файлов проектов.
Плюс еще очень легко работать из разных IDE как с нативным для этой IDE проектом — для всех популярных сред есть плагины генерации файлов проектов.
Небольшое уточнение: maven может использовать локальные репозитории в виде относительного пути к папке(т.е. работает урл не только http:// но и file://). Так что проблем с передачей архива не будет.
На нашем проекте так хранятся пропатченные библиотеки.
На нашем проекте так хранятся пропатченные библиотеки.
Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.
В Eclipse можно сгенерить ant для существующего проекта и дальше работать с ним. Делается это так:
1. Right click по нужному проекту
2. Из контекстного меню выбираем Export…
3. В окне экспорта выбираем Ant Builders
4. Жмем Next и далее следуем подсказкам визарда…
В Eclipse можно сгенерить ant для существующего проекта и дальше работать с ним. Делается это так:
1. Right click по нужному проекту
2. Из контекстного меню выбираем Export…
3. В окне экспорта выбираем Ant Builders
4. Жмем Next и далее следуем подсказкам визарда…
Спасибо я знаю. А Вы пробовали с этим потом работать? Т.е. сказать джуниору — вот скрипт сгенеренный Eclipse — там поменяй в нем пару мест.
Сам я пользуюсь этим в основном для своих личных проектов. А обяснять новичкам приходилось очень редко. Несмотря на то что у нас аплликация большая, новые проекты добавляются редко и при этом просто используются уже существующие скрипты. Среди программеров у нас только 1 — 2 % более-менее плотно знакомы с ant. Остальным это просто не нужно для работы.
Для Java следует использовать Maven. Ant только в тех случаях, когда Maven уже не может сделать что-то. Тем более, что в Maven есть поддержка плагина, который использует Ant таски. Ant более универсален, но для сборок проектов на Java Maven так заточен, что его сложно переплюнуть.
для cross-IDE разработки maven удобнее как минимум тем, что позволяет не только собирать, но и создавать IDE-specific project-файлы. Впрочем, в разных IDE качество maven'а сильно различается, в том же eclipse, увы, он весьма хуже IDEA
Для _новичка_ все же лучше Maven. Не более получаса на изучение основ и уже можно собирать проекты. А добавление нового функционала так вообще словно магия, включается несколькими строчками в конфигурацию. Ант клевый, но только тогда когда он _действительно_ необходим.
Спрошу в тему :)
Имею скрипты на Ant для сборки проектов в production. В скриптах используется replaceregexp. В Ant 1.6.5 — всё было ок. Ant 1.7 — 1.8 — виснет на replaceregexp :(
Делаю в WinXP, IDEA.
Имею скрипты на Ant для сборки проектов в production. В скриптах используется replaceregexp. В Ant 1.6.5 — всё было ок. Ant 1.7 — 1.8 — виснет на replaceregexp :(
Делаю в WinXP, IDEA.
Я на проекте много лет использовал ант. Проект большой несколько десятков модулей и подпроектов. Антовские скрипты работали как часы, но вот когда надо было подключить новую библиотеку или фреймворк это требовало не мало усилий. А разбираться в километрах xml не каждому хотелось. Вторая проблема не было стандартного подхода в написании этих скриптов в некоторых подпроектах сборка происходила совсем другим собособом и чтоб там что то подправить надо было сидеть и изучать. Вообщем в начале года решил перевести всё на мавен.
Почитал восторженые статьи, доки и прикинул что за неделю, полтора управлюсь. В итоге ушло полтора месяца! Это был тихий ужас иногда хотелось лезть на стенку и рвать на голове волосы. Плагины ужасно дырявые, даже стандарные, документации нормальной нет.
Мавен это просто набор хороших идей и подходов сваленых в кучу. Если сравнивать с антом то говоря о первом можно представить что ты сидишь за рулём и ведёщь машину, ты сам знаешь когда надо свернуть налево или направо, а где остановиться. С мавеном ты сидишь где то на заднем сиденьи и пишешь на бумажке водителю куда ехать.
Вообщем я всё-таки перевёл проект на мавен и не жалею. И всем советую, только надо набраться терпения. Разработка пошла веселее, появились стандарты и требования к сборке проектов и теперь все знают как собирать подпроекты или модули.
Почитал восторженые статьи, доки и прикинул что за неделю, полтора управлюсь. В итоге ушло полтора месяца! Это был тихий ужас иногда хотелось лезть на стенку и рвать на голове волосы. Плагины ужасно дырявые, даже стандарные, документации нормальной нет.
Мавен это просто набор хороших идей и подходов сваленых в кучу. Если сравнивать с антом то говоря о первом можно представить что ты сидишь за рулём и ведёщь машину, ты сам знаешь когда надо свернуть налево или направо, а где остановиться. С мавеном ты сидишь где то на заднем сиденьи и пишешь на бумажке водителю куда ехать.
Вообщем я всё-таки перевёл проект на мавен и не жалею. И всем советую, только надо набраться терпения. Разработка пошла веселее, появились стандарты и требования к сборке проектов и теперь все знают как собирать подпроекты или модули.
Поняв недостатки Maven, Apache потихоньку переходит на новую систему билдинга проектов, названную Ivy. Основное отличие от Maven2 — это именно интеграция с Ant-ом. Собственно Ivy — это не более чем облегченный менеджер зависимостей, а билдинг модулей осуществляется именно Ant-ом.
Основной недостаток Maven состоит в том, что сборка модуля осуществляется только при помощи стандартных плагинов или расширений, которые плохо документированы, и очень не гибкие. Адаптировать сборку для неординатрого случая в Maven бывает очень сложно. В Ivy же можно иметь абсолютно свой сценарий сборки для каждого конкретного случая.
P.S. в последнее время стал смотреть в сторону OSGi. OSGi bundles уже внутри прописывают все зависимости. Имеются несколько репозиториев с бандлами.
Основной недостаток Maven состоит в том, что сборка модуля осуществляется только при помощи стандартных плагинов или расширений, которые плохо документированы, и очень не гибкие. Адаптировать сборку для неординатрого случая в Maven бывает очень сложно. В Ivy же можно иметь абсолютно свой сценарий сборки для каждого конкретного случая.
P.S. в последнее время стал смотреть в сторону OSGi. OSGi bundles уже внутри прописывают все зависимости. Имеются несколько репозиториев с бандлами.
Когда-то мы использовали Maven первой версии. В проектах кроме Java использовались DSL, так что писали даже свои плагины. Как-то жили, но самой большой проблемой было создание нового рабочего места разработчика. Разные версии Maven, разные версии плагинов — всё это приводило к тому, что некоторые проекты напрочь отказывались собираться свежеустановленным Maven'ом, а у старых разработчиков проблем не было. Выхода второго Maven я не дождался — перевел все проекты на Ant + Ivy. Ant для сборки (прост и стабилен), Ivy для управления зависимостями (гораздо гибче, чем первый Maven).
А чтобы не писать build.xml для каждого нового проекта, написал библиотечный build.xml, который делает 99% работы в простых проектах и 90% в сложных. Оставшиеся 10% дописываю в build.xml проекта. Трансляция DSL (JavaCC, Antlr, TreeDL), компиляция Java, создание JavaDoc, тесты, упаковка дистрибутива — из коробки.
В качестве бонуса — можно создавать билдеры для трансляции DSL из Eclipse: при изменении исходных файлов запускаются те же Ant'овские цели, что и из консоли.
Для сборки любого проекта достаточно установить Ant и достать исходники проекта из svn!
Делал для себя, документация минимальна, проект не пиарю, хотя исходники открыты. Но для любопытствующих ссылку дам: BuildBase. И на вопросы отвечу.
А чтобы не писать build.xml для каждого нового проекта, написал библиотечный build.xml, который делает 99% работы в простых проектах и 90% в сложных. Оставшиеся 10% дописываю в build.xml проекта. Трансляция DSL (JavaCC, Antlr, TreeDL), компиляция Java, создание JavaDoc, тесты, упаковка дистрибутива — из коробки.
В качестве бонуса — можно создавать билдеры для трансляции DSL из Eclipse: при изменении исходных файлов запускаются те же Ant'овские цели, что и из консоли.
Для сборки любого проекта достаточно установить Ant и достать исходники проекта из svn!
Делал для себя, документация минимальна, проект не пиарю, хотя исходники открыты. Но для любопытствующих ссылку дам: BuildBase. И на вопросы отвечу.
Sign up to leave a comment.
Сборка Java приложений при помощи Apache Ant, quick start