на всяк случ. мож кому легче будет :
вместо -buildfile можно -f :

если есть в текущей папке файл build.xml - то ант сам его хватанёт.
ant stop
Если такого нету - тогда следует файл явно указать.
то есть


В общем та же идеология замечательной утилитки make (которую, я, дурак, раньше недолюбливал)

По поводу частичной сборки: так же как и make - компилит несуществующие или "освежает" старые. Зачастую clean можно не делать.
Когда пересобирал проект - очень пригодилось - поменял мааахонький кусочек - оно его перекомпилило - и всё не сидишь по 5 минут в монитор не втыкаешь

Другие программы можно запускать с помощью таска <apply>. Я например запускаю компилятор делфи.

hi, вот хочу аЛексус первый плюсик поставить, как это можно сделать?

Не вопрос.

Кстати есть одно дополнение для тех кто собирает проекты делфи на Анте.
Если ваш файл сборки будет не в той же директории где и *.dpr, то он не будет нормально компилировать в том случае если есть dcc32.cfg. Я эту проблему решил путем разделения файла сборки на два: один основной, а другой только для компиляции.
Основной файл выглядит примерно так:


А второй, который копируется в раб. директории я указал выше.

если у кого-нить есть какие-нибудь замечания или советы, жду!
да и обратите внимание на <parallel> и <sequential>, очень полезные штуки, значительно уменьшает время сборки!

В дополнение ссылка на статью по Ant - http://www.opennet.ru/base/dev/ant_10.txt.html.

Все таки не могу решить проблему. Мне необходимо с помощью другой программы обработать исходник и поменять содержимое doclet тега. Проблема состоит в том, что данную операцию нужно сделать только для изменившихся исходников, которые определит ant и делать мне это нужно непосредственно перед компиляцией каждого из изменившихся исходников.
В принципе в <javac> task можно включить опцию debug="on" и вывести в файл результаты компиляции, где и будут перечислены компилирующиеся файлы. Но во-первых, его парсить нужно и во-вторых, получаешь набор исходников, которые уже откомпилированы. А мне необходимо непосредственно перед компиляцией обработать изменившийся исходник.



Есть одна маленькая загвоздка, на которую никто из осваивающих ant не обращает внимание, а потом теряет время.
!!! Если структура каталогов в точности не соответствует структуре пакетов, то ant будет компилить все подряд вне зависимсоти от того каких ты опций в task'e не понаставишь. Другими словами, дерево каталогов, в которые будут ложиться классы будет сформировано согласно структуре пакетов, а исходники могут лежать в дереве каталогов, которое не соответствует в точности дереву каталогов классов. Ведь сравнение изменившегося исходника ведется по классу, который должен лежать в подобной структуре каталогов. Поэтому нужно обязательно проверить соответствие дерева каталогов классов и дерево каталогов исходников на соответствие. Тогда ant будет компилировать только изменившиеся исходники.
И еще хорошо бы воспользоваться task'ом <depend>.


не хочется лезть в документацию, но интересно знать за счет чего это происходит. 

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


Меняешь файлы и компилируешь повторно. Идея плохая, но работать должно.

Хотелось бы дополнить начинателя:
Тег property: однажды сознанная property уже никогда не меняет своего значения. Это, в принципе, есть в статье на opennet

Тег condition: позволяет реализовать ветвление. Пример:

В случае успешной провеки условия в теле элемента condition будет установлена переменная name (значение "ok_value"). Если условие не верно, переменная установлена не будет. Поэтому, если нужно построить конструкцию if ... else ..., то для этого достаточно после condition добавить тег proprety, в котором установить значение для неверного условия.
   

Это сообщение отредактировал(а) sandello - 18.4.2006, 14:50

Задача следующая: есть increaseVersion.jar который увеличивает версию в java исходнике, в теге @version. Увеличивает по заданному правилу для определеленного формата x.xx или x.x. Если в какой-то исходник вносится изменение, то его версию нужно увеличить при следующей компиляции. Естественно ant найдет все изменившиеся исходники и скомпилирует только их. Но мне нужно перед тем как он их найдет увеличить версию. Если увеличивать версию после компиляции, то эти файлы снова окажутся измененными и ant их будет компилировать вечно.
Можно ли каким-то образом вклинить запуск этого jar'ника в таск <javac> и непосредственно перед компиляцией увеличивать версию только тех исходников, в которые вносились изменения?
Система контроля версий в данном случае не подходит по нескольким причинам:
- версия класса должна меняться в исходнике после каждого изменения/компиляции а не после коммита
- библиотека небольшая и разрабатывается и собирается одним человеком, т.е. отсутствуют там всякие мерджи версионные ветки
- откаты тоже не нужны
- ну и система контроля версий и место дополнительное ест и время потихоньку тоже. 

Ты немного не понял. Я предлагал сделать что-то вроде:


А вот на счет системы контроля версии - ты не прав. Именно она очень удобна для этой задачи. На примере Subversion могу предложить несколько вариантов:
1. С использованием Keywords - тогда в каждый файл можно затолкать номер ревизии
2. С использованием svn status можно получить список изменных файлов без компиляции

Я реализовал 3 вариант :-) Основная особенность - выбор, что будем увеличивать (version.subversion.patch.bugfix), решаю я. Для этого у ant'овского скрипта торчат наружу одноименные цели. Каждая такая цель увеличивает цифирку в определенной строке специального файла. Дальше - дело техники :-)
  

Это сообщение отредактировал(а) sandello - 19.4.2006, 11:57

svn только начинаю осваивать и толком данную задачу быстро не решу. Попробую третий вариант :-), может у тебя есть простой пример? 

Лови работающий скрипт


Добавлено @ 06:19 
Он еще много чего интересного делает :-) 

Хороший пример, попробую обстричь его для своих целей. 

Все добавил, нашел еще и commoms-logging.jar
но




смотрю в jasper, package org.apache.juli.logging существует, а самого LogFactory нет
И где его искать?

Tomcat 6.0, Ant 1.7.0

Добавлено через 11 минут и 19 секунд
вот что еще нашел, но перевести это не смог

drHip, я пробовал тогда под Ant 1.6. В понедельник поэкспериментирую с семеркой, попробуем разобраться.