Как вы «реорганизуете» файлы ant build.xml? - PullRequest
14 голосов
/ 17 апреля 2009

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

Каковы рекомендации пользователей ant по предотвращению взрыва файлов сборки ant?

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

Ответы [ 5 ]

13 голосов
/ 17 апреля 2009

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

Проверьте также эту статью о " функциях ant для больших проектов ".

5 голосов
/ 17 апреля 2009

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

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

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

3 голосов
/ 21 апреля 2009

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

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

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

3 голосов
/ 17 апреля 2009

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

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

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

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

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

1 голос
/ 17 апреля 2009

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

...