Есть каталог с кучей подкаталогов.
Во многих подкаталогах есть билдфайлы.
Какие есть способы запуска билдфайлов по всему дереву?

Здравствуйте, Аноним, Вы писали:

А>Есть каталог с кучей подкаталогов.
А>Во многих подкаталогах есть билдфайлы.
А>Какие есть способы запуска билдфайлов по всему дереву?

subant

Мне нужно вызвать билд-файлы в подкаталогах либо в каком-то фиксированном порядке, либо хотя бы чтобы порядок был нефиксироанным(выбранным антом а не мной), но всегда одним и тем же.
Насколько я вижу, если использовать fileset или dirset, то порядок может быть всякий раз — разный.
Если же использовать filelist, то порядок будет всегда таким как указано мной, но в этом случае нельзя сказать "исполнить все build.xml в подкаталогах". Нужно явно прописать путь ко всем build.xml файлам.
Это так?

Здравствуйте, Аноним, Вы писали:

А>Мне нужно вызвать билд-файлы в подкаталогах либо в каком-то фиксированном порядке, либо хотя бы чтобы порядок был нефиксироанным(выбранным антом а не мной), но всегда одним и тем же.
А>Насколько я вижу, если использовать fileset или dirset, то порядок может быть всякий раз — разный.
А>Если же использовать filelist, то порядок будет всегда таким как указано мной, но в этом случае нельзя сказать "исполнить все build.xml в подкаталогах". Нужно явно прописать путь ко всем build.xml файлам.
А>Это так?

Конечно. Ты строишь dependency tree? Поэтому и надо собирать в определенном порядке?

DZ>Конечно. Ты строишь dependency tree? Поэтому и надо собирать в определенном порядке?

Ну пока еще непонятно. Пока только думаю.
Но скорее всего будет dependency tree.
Но это не для сборки а для тестинга. Причем не только средствами junit-а.
Да и даже если каждый build.xml будет независимым, то все равно хотелось бы иметь стабильный порядок вызовов.

Здравствуйте, _java_, Вы писали:

__>Ну пока еще непонятно. Пока только думаю.
__>Но скорее всего будет dependency tree.

См. ivy


__>Но это не для сборки а для тестинга. Причем не только средствами junit-а.
__>Да и даже если каждый build.xml будет независимым, то все равно хотелось бы иметь стабильный порядок вызовов.

Как-то не согласовывается одно с другим. Либо ты прописываешь порядок ручками, либо указываешь, что хочется все из подпапок начиная с определенной. Это крайние случаи. Возможны вариации, когда у тебя есть равноранговые наборы проектов, которые надо собирать, например, есть набор1, в котором два компонента, не зависящие друг от друга; набор2, в котором тоже два. Тебе не важно, в каком порядке будут собираться компоненты, главное, чтобы 21 и 22 собирались после того, как будут собраны 11 и 12. Тогда можно тупо запустить сначала сборку для набора1, потом для набора2 (можно посмотреть parallel)

В общем, непонятна задача, в качестве решения которой ты пытаешься придумать какой-то вариант сборки.

DZ>В общем, непонятна задача, в качестве решения которой ты пытаешься придумать какой-то вариант сборки.

Задача простая.
Есть дерево каталогов с антовскими билдфайлами.
Эти билд-файлы запускают либо junit-овские тесты, либо какие-то самописные тулзовинки, которые проверяют часть функциональности системы.
Все эти "тесты" пишут отчет в какой-то файл.
Хотелось бы чтобы можно было добавлять "тесты" в дерево каталогов, не меняя при этом главного build.xml, который запускает все тесты.
Но в то же самое время хотелось бы чтобы порядок вызовов дочерних build.xml не менялся.
Например для того чтобы можно было сравнить файлы отчетов за разное время и увидеть разницу.
Если порядок вызовов не изменится, то разницу в отчетах найти можно будет легко.
Если же порядок будет разный, то тогда сравнивать отчеты будет невозможно.

Здравствуйте, _java_, Вы писали:

__>Задача простая.
__>Есть дерево каталогов с антовскими билдфайлами.
__>Эти билд-файлы запускают либо junit-овские тесты, либо какие-то самописные тулзовинки, которые проверяют часть функциональности системы.
__>Все эти "тесты" пишут отчет в какой-то файл.
__>Хотелось бы чтобы можно было добавлять "тесты" в дерево каталогов, не меняя при этом главного build.xml, который запускает все тесты.
__>Но в то же самое время хотелось бы чтобы порядок вызовов дочерних build.xml не менялся.
__>Например для того чтобы можно было сравнить файлы отчетов за разное время и увидеть разницу.
__>Если порядок вызовов не изменится, то разницу в отчетах найти можно будет легко.
__>Если же порядок будет разный, то тогда сравнивать отчеты будет невозможно.

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