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

Question

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

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

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

Answer 1

вы можете быть заинтересованы в:

• <import>
• <macrodef>
• <subant>

Проверьте также эту статью на "ant features for big projects".

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

1. удалить копировать/вставить код
2. определить значения по умолчанию

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