Как вы "рефакторируете" ant файлы build.xml?

Я работаю над большой С++-системой, созданной с помощью ant + cpptasks. Он работает достаточно хорошо, но файл build.xml выходит из-под контроля из-за стандартной операционной процедуры для добавления новой библиотеки или исполняемой цели для копирования и вставки других правил lib/exe (которые уже довольно велики). Если это был "правильный код", он будет кричать на рефакторинг, но, будучи новичком ant (больше используется для создания или решений VisualStudio), я не уверен, что это за варианты.

Что представляют собой ant лучшие методы пользователей для остановки разрастания файлов сборки ant?

Один очевидный вариант - создать build.xml через XSLT, определяя наши собственные теги для часто повторяющихся шаблонов. Кто-нибудь это делает, или есть ли лучшие способы?

ОТВЕТЫ

Ответ 2

Если правила повторяются, вы можете разложить их в макрос ant с помощью макроопределения и повторно использовать этот макрос.

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

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

Ответ 3

В общем случае, если ваш файл сборки является большим и сложным, то это четкое указание на то, что способ, которым вы располагаете свой код, с точки зрения папок и пакетов, является сложным и слишком сложным. Я нахожу, что сложный ant script - это чистый запах плохо выложенной базы кода.

Чтобы исправить это, подумайте о том, как выкладывается ваш код. Сколько у вас проектов? Знают ли эти проекты, как построить себя с помощью master build script, который знает, как объединить отдельные проекты/приложения/компоненты вместе в большее целое.

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

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

Вы должны уметь видеть и понимать структуру и структуру базы кода, просто просматривая скрипты сборки. Если они/не являются чистыми и понятными, то и ваш исходный код не является.

Ответ 4

Используйте файлы Antlib. Это очень чистый способ

  • удалить копию/вставленный код
  • определить значения по умолчанию

Если вы хотите увидеть пример, вы можете взглянуть на некоторые из build script Я пишу для своего проекты песочницы.

Ответ 5

Я бы попробовал Ant -Ivy- гибкий менеджер зависимостей. Мы недавно начали использовать его для некоторых из наших более сложных систем, и это работает как шарм. Преимущество здесь в том, что вы не получаете накладные расходы и переход на maven (он использует ant цели, поэтому будет работать с вашей текущей настройкой). Вот сравнение между ними.