Лучший способ изменить константы в процессе сборки Java

Поместите свои значения в файл свойств, скажите "myapp.properties" и затем загрузите их в Ваши константы от пути к классу при запуске (см. ниже для того, как это вписывается в процесс сборки):

public class Constants
{
    private static final Properties props = new Properties();
    public static final String MY_CONSTANT;

    static
    {
        InputStream input = Constants.class.getResourceAsStream("/myapp.properties");
        if(input != null)
        {
           try
           {
              properties.load(input);
           }
           catch(IOException e)
           {
              // TODO log error
           }
        }

        // Initialize constants (dont' forget defaults)
        MY_CONSTANT = properties.getProperty("constant", "default");
        // .. other constants ...
    }
}

Теперь, имейте файл раздельного имущества для каждого брендинга. Передайте его имя к МУРАВЬЮ через-D или build.properties и скопируйте файл в Ваш каталог сборки прямо, прежде чем Вы будете сотрясать (или война) его.

Очевидно, код выше будет работать, но существует много способов, которыми можно очистить его и сделать его пуленепробиваемым.

Существует также "пружинный" путь, который должен использовать файл свойств и боб, который вытягивает значение от свойств и вводит их в классы, которым нужны они, например:

<bean id="propertyPlaceholder"  class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location" value="classpath:configuration.properties" />
</bean>

и затем, можно ввести свойства с "подобным муравью" синтаксисом:

<bean id="connectionPool"  class="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource">
    <property name="databaseName" value="mydb" />
    <property name="url" value="${db.url}" />
    ...

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

public class Foo {
 public static final int SOME_CONSTANT=1;
..
}

public class Bar {
  ...
   int x=5+Foo.SOME_CONSTANT;
  ...
}

Если Вы затем измените SOME_CONSTANT в Нечто к 2, но не перекомпилируете Панель, то Панель сохранит значение 1 для SOME_CONSTANT, поскольку статический финал компилируется в (так как компилятор видит, что это не должно должно быть когда-либо понимать их снова).

Я предпочитаю использовать фильтр expandproperties муравья вместо задачи замены. С задачей замены файл типа "build" имеет тенденцию расти, чтобы быть главным образом токенизацией. expandproperties позволяет Вам встроить свойства муравья непосредственно в Ваш текст.

<copy file="from" tofile="to">
  <filterchain>
    <expandproperties />
  </filterchain>
</copy>

У меня есть решение, которое работает по мере необходимости на эту конкретную ситуацию. Я использовал задачу замены Муравья в сочетании с "сохраненной" версией постоянного класса:

<target name="one" description="constant substitution #1">
  <delete file="./tme3/MyConst.java" />
  <copy file="./save/MyConst.java" tofile="./tme3/MyConst.java" />
  <replace file="./tme3/MyConst.java" token="@BRANDING@" value="ONE_BRAND"/>
  <replace file="./tme3/MyConst.java" token="@STYLESHEET@"
           value="../stylesheet/onebrand.css"/>
  <replace file="./tme3/MyConst.java" token="@FAVICON@" value="../images/onebrand.ico"/>
  <replace file="./tme3/MyConst.java" token="@SHOW_LANGUAGES@" value="false"/>
</target>

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

Спасибо все до одного для больших ответов.

Используйте файлы свойств Муравья и сборку с "-Dbrand=X".