Лучшее место для файлов ant build.xml?

Question

Для тех из вас, кто использует Ant в нескольких проектах, куда вы помещаете файлы build.xml? Вы помещаете один в каждый проект, или вы помещаете их в отдельный проект, который содержит все ваши файлы, связанные с Ant?

Обычно рекомендуется помещать build.xml в каждый проект. Но это имеет несколько недостатков:

• Это затрудняет повторное использование общих целей в нескольких проектах.

• Иногда вы хотите использовать Ant для экспорта проекта из системы контроля версий и его развертывания. Очевидно, что вы не можете сделать это, если файл сборки находится в самом проекте.

Но если вы разместите их в одном месте:

• Люди должны знать свое местоположение, чтобы использовать их; они не могут просто использовать "ant -find", чтобы найти файл текущего проекта.

• Вы не можете иметь разные инструкции по сборке для разных веток проекта.

Что вы, ребята, делаете?

РЕДАКТИРОВАТЬ : Спасибо за хорошие предложения до сих пор. Что касается Maven, то это не проекты Java, и у меня сложилось впечатление, что Maven предназначен только для Java.

Answer 1

Поместите файлы Ant вместе с проектом. Это стандарт de facto , рекомендованный создателем Ant. Я постараюсь решить некоторые из затронутых вами вопросов:

• Повторное использование общих целей должно выполняться с использованием методов, описанных Эриком Хэтчером в его книге Разработка Java с помощью Ant . По сути, вы извлекаете всю общность в некоторые файлы верхнего уровня, от которых «наследуются» все остальные файлы Ant.

• Использование Ant для экспорта проекта из системы управления версиями мне кажется странным, но если вы хотите сделать это, используйте другой файл Ant :-) Вы можете сделать цель, например, ant export -Dproject=foo/bar.

Для Ант, я рекомендую вам взять эту книгу - в ней много полезных приемов.

Реальная рекомендация, которую я бы дал, - это сбросить Ant и перейти на Maven - как это делал Apache Software Foundation (они поддерживают Ant и Maven).

Answer 2

Если вы работаете с независимыми проектами, вы можете:

• поместите свой build.xml на верхний уровень
• помещает общие определения Ant (Antlib) в другой проект (например, config)
• используйте svn: externals для импорта общего определения Antlib (из 'config') в ваш проект

РЕДАКТИРОВАТЬ Уловка с svn: externals заключается в том, что если вы ссылаетесь на HEAD некоторых распространенных файлов, может случиться так, что они изменятся через пару месяцев / лет. Поэтому каждый раз, когда вы ставите теги, вы должны изменять svn: externals, чтобы указывать на исправленную версию включенного проекта. Это может пригодиться, когда проект должен быть перестроен спустя годы после его последней сборки.

Answer 3

Я бы ожидал, что файл сборки Ant будет расположен в верхней части проекта (уже тяжело смотреть на файл сборки, чтобы "узнать", как создать проект, так что если я сначала найду его, это сведет меня с ума). Теперь, касаясь всех упомянутых вами недостатков, я хочу сказать: почему бы вам не использовать Maven ?

Answer 4

Мое эмпирическое правило - поместить файл build.xml в каталог, в котором есть ссылки на все файлы. Другими словами, никакие относительные пути не должны начинаться с "../". Там, где я живу, это обычно означает помещение его в каталог «trunk», в котором находятся src, lib, build, docs и т. Д.

Благодаря этому пути в файле становятся чище, и становится понятно, как построить проект.

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

Answer 5

То, как я это делал, в прошлом (сейчас я просто использую Maven):

• Иметь build.xml в корне каждого проекта
• Создайте всеобъемлющий build.xml для всех проектов и разместить его в ствол моего хранилища
• Всеобщий buid.xml имеет контрольные задания для каждого проекта. Я думаю, когда вы упомянули экспорт из хранилища, вы фактически означало импорт.
• Общий файл сборки также определяет зависимости, если таковые имеются
• Вы можете обновить отдельные проекты, используя отдельный файл сборки каждого проекта
• Если у вас есть определенные общие задачи, вы можете наследовать от общего файла сборки, а также от кого-то другого.

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