Сборка Java приложений при помощи Apache Ant, quick start

[Timmmm]

Уделив изучению Maven тоже время что и на ant, собирать проекты вы будете намного быстрее. Ant по моему уже устарел.

[alkaruno]

Ant не устарел. Этот же Maven использует ant внутри себя. Просто ant для всеобщих задач. А вот для сборок проектов на Java и существует Maven. Лучше Maven в этом плане ничего нет и не будет. Но и Ant хоронить не надо.

[googol]

Лучше Маven ничего не будет? o_0

Что одно (ant) что другое (maven) говно. Хороши для приложений уровня hello-world для более сложных проектов абсолютно не подходят. Java билд системы еще ждут своего будущего.

PS Рекомендую взглянуть на Rake, Buildr, sbt.

[thevery]

gradle?

[googol]

Для минусующей школоты — я автор 2 плагинов у первому мавену и одного ко второму. Так что я знаю о чем говорю.

PS В конце года Гугл должен выпустить свою билд систему ориентированную на большие проекты, это должно быть намного интереснее.

[Gregy]

А можно по подробнее что не устраивает в Maven 2 для больших проектов?

[Timmmm]

Стало еще больше интересно что Вас конкретно не устраивает?

[Semenych]

Спорный вопрос. Особенно насчет времени. У мавена есть один довольно существенный недостаток. Библиотеки он берет из интеренета. Это кончено хорошо. Но:
1. Нужной библиотеки в доступных репозиториях может банально не быть.
2. Если Вам надо попатчить Jboss.seam.1.2.jar то патченную библиотеку надо где-то хранить (для всех 6 членов команды сидящих в 3 разных городах)
3. Если через 3 года вы сделаете checkout проекта из SVN у Вас нет 100% гарантии что все нужные библиотеки будут доступны, а если они будут доступны, что war который будет собран бует точно такой же функционал как тот который Вы собирали 3 года назад.

Все это конечно решаемо, но если Вам нужен 100% контроль над тем что получается в результате, сил приходится прикладывать заметно больше чем с ant.

[Timmmm]

1. Кроме базового репозитория есть альтернативные. За последние год-два не нашел только одну библиотеку по работе с json. Выбрал другую.
2. Интересно увидеть выход который предлагаете вы. Решение есть, поднять свой репозитарий и в нем хранить все что вам понадобиться.
3. Эта проблема организации разработки, мавен поддерживает версионность. Интересно как вас спасет ант в этом случае.

Я 100% контролирую результат который я получаю с Maven.

[Semenych]

Я не сомневаюсь что у Вас все хорошо. Вопрос в том, сколько времени ушло на обучение, сколько тратится на поддержание состояния — «хорошо».

По поводу #2 — решение простое берется seam, правится и кладется в svn как и остальный библиотеки. Про свой репозиторий я в курсе, проблема в том, что никто не гарантирует наличия в нем правленного jar-а через пол года.

Еще раз мавен хорошо. Но правильно использовать его джуниору сложно. Фактически не реально. Ant вполне реально — проверено на живых джуниорах-добровольцах.

[Timmmm]

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

Хммм странно, как это никто не гарантирует? Как тогда гарантировать его наличие в svn'е?

Возможно, Вы правы. После того как я пересел на maven вся сборка проходит в разы быстрее, можно даже сказать что за меня все делает maven.

[Semenych]

ну если коротко maven vs ant:

Мавен более декларативный и что важно вл многом сам отслеживает зависимости артефактов. В этом его сила и слабость одновременно.

Ант, проще, нагляднее, более процедурный (для студента как правило идея не процедурной системы сборки вообще тяжела) и более стабильный.

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

С мавеном, особенно если у вас свой репозиторий такой трюк не проходит.

BTW мавен особенно любим индусами которые обожают строить инфраструктуру из 33 серверов и репозиториев.

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

Ant более всеяден.

[FlashXL]

Конкренто в моем случае Мавен очень удобен тем, что с ним не надо вкладывать кучу библиотек. У нас есть около 15 довольно схожих по структуре проектов, и почти все используют примерно одинаковый набор библиотек. Так вот передать разработчику в другой город все эти проекты стоит немалого времени (в провинциях интернеты не так быстры, как хоетлось бы), а с Мавеном все проекты из почти гига превращаются буквально в 10-15 Мб.

Плюс еще очень легко работать из разных IDE как с нативным для этой IDE проектом — для всех популярных сред есть плагины генерации файлов проектов.

[skocher]

Небольшое уточнение: maven может использовать локальные репозитории в виде относительного пути к папке(т.е. работает урл не только http:// но и file://). Так что проблем с передачей архива не будет.

На нашем проекте так хранятся пропатченные библиотеки.

[Ermak]

Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.

В Eclipse можно сгенерить ant для существующего проекта и дальше работать с ним. Делается это так:
1. Right click по нужному проекту
2. Из контекстного меню выбираем Export…
3. В окне экспорта выбираем Ant Builders
4. Жмем Next и далее следуем подсказкам визарда…

[Semenych]

Спасибо я знаю. А Вы пробовали с этим потом работать? Т.е. сказать джуниору — вот скрипт сгенеренный Eclipse — там поменяй в нем пару мест.

[Ermak]

Сам я пользуюсь этим в основном для своих личных проектов. А обяснять новичкам приходилось очень редко. Несмотря на то что у нас аплликация большая, новые проекты добавляются редко и при этом просто используются уже существующие скрипты. Среди программеров у нас только 1 — 2 % более-менее плотно знакомы с ant. Остальным это просто не нужно для работы.

[Semenych]

В общем-то нормальная ситуация. Просто я последние пол-года столкнулся с необходимостью засетапить где-то десяток новых проектов в которых работают в основном джуниоры. Проекты простые, но увы, это не отменяет необходимости их собирать.
Тут то я и понял почему ряд студентов так сильно не любит Яву.

[Zorkus]

Ряд студентов не любит все то, чего они не могут или не хотят понять. Пусть они радуются, что вы не заставляете их писать на Common Lisp-e.

[alkaruno]

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

[thevery]

для cross-IDE разработки maven удобнее как минимум тем, что позволяет не только собирать, но и создавать IDE-specific project-файлы. Впрочем, в разных IDE качество maven'а сильно различается, в том же eclipse, увы, он весьма хуже IDEA

[skocher]

Это свойство maven по пользе стоит сразу после менеджера зависимостей. А с тех пор как IDEA научилась сама импортировать maven проекты, я всегда начинаю новый проект с настройки под maven.

Для новых разработчиков в команде время настройки проекта сократилось до нескольких минут.

[thevery]

это IDEA с мавеном почти идеально работает, а вот с eclipse'ом граблей с костылей куча…
что, впрочем, не отменяет его полезности

[malkolm]

если учесть, что выбор IDE является почти религиозным, то свойство быть IDE агностиком просто безумно удобно

[malkolm]

Для _новичка_ все же лучше Maven. Не более получаса на изучение основ и уже можно собирать проекты. А добавление нового функционала так вообще словно магия, включается несколькими строчками в конфигурацию. Ант клевый, но только тогда когда он _действительно_ необходим.

[Semenych]

Проблема в том, что я на 100% уверен что новичка магия строго противопоказана. Наоборот новичок обязан прочувствовать что и как надо делать.

[malkolm]

Мне мавен дал быстрый старт. За вышеуказанные полчаса разобрался как нужно организовывать проект, чтобы он стал IDE независим и дистрибутив для _любой_ ревизии менеджер мог собрать сам, без моей помощи. _Правильная_ магия полезна, там новичку сложно выстрелить себе в ногу.

[johndow]

Спрошу в тему :)
Имею скрипты на Ant для сборки проектов в production. В скриптах используется replaceregexp. В Ant 1.6.5 — всё было ок. Ant 1.7 — 1.8 — виснет на replaceregexp :(
Делаю в WinXP, IDEA.

[thevery]

а standalone ant тоже виснет?

[johndow]

Хм. Проверил щас на 1.8.0 из командной строки — сработало нормально. Видимо что-то в Идее.

[thevery]

ну так добавьте им баг, пусть чинят…

[eugenn]

Я на проекте много лет использовал ант. Проект большой несколько десятков модулей и подпроектов. Антовские скрипты работали как часы, но вот когда надо было подключить новую библиотеку или фреймворк это требовало не мало усилий. А разбираться в километрах xml не каждому хотелось. Вторая проблема не было стандартного подхода в написании этих скриптов в некоторых подпроектах сборка происходила совсем другим собособом и чтоб там что то подправить надо было сидеть и изучать. Вообщем в начале года решил перевести всё на мавен.
Почитал восторженые статьи, доки и прикинул что за неделю, полтора управлюсь. В итоге ушло полтора месяца! Это был тихий ужас иногда хотелось лезть на стенку и рвать на голове волосы. Плагины ужасно дырявые, даже стандарные, документации нормальной нет.
Мавен это просто набор хороших идей и подходов сваленых в кучу. Если сравнивать с антом то говоря о первом можно представить что ты сидишь за рулём и ведёщь машину, ты сам знаешь когда надо свернуть налево или направо, а где остановиться. С мавеном ты сидишь где то на заднем сиденьи и пишешь на бумажке водителю куда ехать.

Вообщем я всё-таки перевёл проект на мавен и не жалею. И всем советую, только надо набраться терпения. Разработка пошла веселее, появились стандарты и требования к сборке проектов и теперь все знают как собирать подпроекты или модули.

[malkolm]

Скорее с мавеном вы ведете машину, а с антом регулируете все шестеренки, дабы работали как надо. И здорово, если в выхлопную трубу не выплевывается бензин, а в бак не заливается вода.

[Throwable]

Поняв недостатки Maven, Apache потихоньку переходит на новую систему билдинга проектов, названную Ivy. Основное отличие от Maven2 — это именно интеграция с Ant-ом. Собственно Ivy — это не более чем облегченный менеджер зависимостей, а билдинг модулей осуществляется именно Ant-ом.

Основной недостаток Maven состоит в том, что сборка модуля осуществляется только при помощи стандартных плагинов или расширений, которые плохо документированы, и очень не гибкие. Адаптировать сборку для неординатрого случая в Maven бывает очень сложно. В Ivy же можно иметь абсолютно свой сценарий сборки для каждого конкретного случая.

P.S. в последнее время стал смотреть в сторону OSGi. OSGi bundles уже внутри прописывают все зависимости. Имеются несколько репозиториев с бандлами.

[allex]

Когда-то мы использовали 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. И на вопросы отвечу.