Java Ant построить несколько выпусков программного обеспечения

Question

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

Как мне построить обе редакции с использованием Ant?

Я имею в виду, внутри кода, насколько я могу видетьНапример, я бы проверил:

if(Editions.PRO)
{
    // 'Pro' edition code
}
else
{
    // 'Normal' edition code
}

, и поскольку Editions.PRO является "статическим окончательным логическим значением" , будет скомпилирована только одна часть кода .

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

Итак, "условная компиляция" (выше)метод кажется мне лучшим.
Как мне реализовать это в Ant?

Может ли Ant манипулировать значением "Editions.PRO" в своем файле?
Это на самом деле неэто звучит не очень хорошо для меня.
Вместо этого я думал о замене файлов (с помощью команд Ant) или, что еще лучше, исключая (настоящий, dev) файл, которыйопределяет "Editions.PRO" и добавить в качестве пути к классу еще одну папку , которая имеет тот же файл, но с "Edit"ion.PRO "настроен соответственно (к нужной редакции) .... Надеюсь, у меня все ясно.

Как / вы бы это сделали?

Answer 1

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

Затем создайте две цели муравья, цель "pro" и цель "demo".Затем каждая цель исключает компиляцию или упаковку (в зависимости от того, где вы хотите провести различие) реализаций абстрактных интерфейсов, не относящихся к конкретной редакции.

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

Попытка встроить функциональность, если операторы принимают неверный путь.Если вы сделаете это для компиляции кода, вам понадобится как профессиональный, так и демонстрационный код одновременно, чтобы создать профессиональный или демонстрационный продукт.Кроме того, вам (вероятно) необходимо отправить оба набора кода вместе с демонстрационным продуктом.Это оставляет открытой возможность для человека нанести ущерб вашему механизму выбора pro / demo и активировать код pro версии в демонстрационном продукте.

Answer 2

Замена токенов в коде Java работает для меня.Я использую что-то вроде этого перед задачей компиляции:

<copy todir="${target.dir}/java" filtering="false">
    <fileset dir="${src.dir}/java"/>
</copy>
<replace dir="${target.dir}/java" value="DEMO_MODE = ${demo.mode}">
  <replacetoken>DEMO_MODE = true</replacetoken>
</replace>

Сначала я копирую файлы Java во временную папку, затем заменяю токены.Javac эти скопированные файлы.$ {demo.mode} может быть задан в качестве параметра даже в командной строке или в файле свойств.DEMO_MODE является общедоступной статической конечной логической переменной в классе.

Еще две вещи, которые могут быть вам полезны:

Вы можете настроить условные присваивания свойств в целях:

<condition property="distribution.postfix" value="-demo" else="">
<equals arg1="${demo.mode}" arg2="true" />
</condition>

И вы можете использовать , если и , если только условия для целей:

<target name="demotarget" depends="jar" if="demo.mode">
       ...
</target>

На самом деле, я бы предпочел модульность и другие цели для выпусков PRO и DEMO,возможно, переключаемые функции, но мы используем эти приемы для чего-то другого, в частности для выпусков «Разработка против производства»: код разработки содержит больше журналов отладки, которые мы не хотим видеть в производственном программном обеспечении с конфигурацией logLevel = DEBUG.Кроме того, производственный код запутан, а разработка - нет, поэтому последний создает, например, читаемые трассировки стека.

Answer 3

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

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