Лучшая практика для модификации кода во время сборки муравья

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

Наша первая идея заключалась в использовании системных свойств, но из-за нестабильности среды развертывания (другой способ сказать «системные администраторы делают странные, нечестивые жуткие вещи») мы хотели бы, чтобы они были жестко запрограммированы.

По сути, я вижу 4 возможности добиться этого в ant:

1. используйте для токена в классе

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

2. скопируйте файл, сделайте замену в копии, скомпилируйте копию, удалите копию

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

3. скопируйте файл, заменить маркер на оригинал, скомпилировать, заменить окрашенный оригинал копией

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

4. создать файл с нуля в скрипте сборки / сохранить файл за пределами исходного пути

   Это улучшение по сравнению с первыми тремя, поскольку нет временных зависимостей, но компилятор / IDE очень недовольны, поскольку не обращают внимания на класс. Красные маркеры пугающе некрасивы.

Что вы думаете об альтернативах?

Есть ли какие-нибудь передовые методы для этого?

Надеюсь, я упустил совершенно разумный подход.

Спасибо

ИЗМЕНИТЬ замените окрашенный оригинал копией

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

Что вы думаете об альтернативах?

Есть ли какие-нибудь передовые методы для этого?

Я очень надеюсь, что упустил совершенно разумный подход.

Спасибо

EDIT замените окрашенный оригинал копией

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

Что вы думаете об альтернативах?

Есть ли какие-нибудь передовые методы для этого?

Надеюсь, я упустил совершенно разумный подход.

Спасибо

ИЗМЕНИТЬ

Что вы думаете об альтернативах?

Есть ли какие-нибудь передовые методы для этого?

Я очень надеюсь, что упустил совершенно разумный подход.

Спасибо

EDIT

Что вы думаете об альтернативах?

Есть ли какие-нибудь передовые методы для этого?

Я очень надеюсь, что упустил совершенно разумный подход.

Спасибо

EDIT В итоге мы использовали манифест для хранения номера сборки и версии системы в атрибуте Implementation-Version , unsing MyClass.class.getPackage (). GetImplementationVersion () . Я обнаружил, что это решение было одним из ответов на этот поток , который был размещен в комментарии andersoj