You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Ja...@rzf.fin-nrw.de on 2006/06/01 08:36:55 UTC
AW: Targeting Multiple Environments
<property environment="ENV"/>
<property file="build.properties"/>
<property name="ENV.TARGET_ENV" value="default"/>
<property file="${ENV.TARGET_ENV}.properties"/>
With that you could specify what to load:
- ant -DENV.TARGET_ENV=???
- environment variable TARGET_ENV=???
- specify ENV.TARGET_ENV in build.properties
(- falling back to a default value)
If you want to load computer specific configuration you could do
<property file="${ENV.COMPUTERNAME}.properties"/>
or for user specific
<property file="${user.name}.properties"/>
Jan
>-----Ursprüngliche Nachricht-----
>Von: Anderson, Rob (Global Trade) [mailto:Rob.Anderson@nike.com]
>Gesendet: Mittwoch, 31. Mai 2006 18:18
>An: Ant Users List
>Betreff: RE: Targeting Multiple Environments
>
>I use the same strategy, except I use plain old property files
>instead of xml. I have also added a user-friendly error
>message or input task if the TARGET_ENV prop is missing:
>
><fail unless="TARGET_ENV">You must specify TARGET_ENV on the
>command line. For example...
>ant -DTARGET_ENV=dev deploy</fail>
>
>Or:
>
><target name="getTargetEnv" unless="TARGET_ENV"> ...
>
>Why are you not satisfied with this solution?
>
>-Rob A
>
>> -----Original Message-----
>> From: Kanjo, Samer [mailto:SKanjo@tribune.com]
>> Sent: Wednesday, May 31, 2006 6:26 AM
>> To: Ant Users (E-mail)
>> Subject: Targeting Multiple Environments
>>
>> I am curious as to how others are using Ant to target multiple
>> environments such as development, test, training, and production. In
>> my world each environment typically has its own set of databases,
>> servers, and application servers.
>>
>> What I have done is externalize all properties into a set of
>property
>> files that end with the target environment name (The target
>> environment names are dev, test, train, and prod). So if I had a
>> properties file named "myprops.xml" included in the build I would
>> create one for each environment naming the files as such:
>> "myprops.xml.dev", "myprops.xml.test", "myprops.xml.train",
>> "myprops.xml.prod". The build script would check for an environment
>> variable named TARGET_ENV and attempt to load the file "myprops.xml"
>> suffixed with the value of TARGET_ENV. Once loaded all the
>properties
>> associated with that target are available to the build script.
>>
>> In order for this to work I must specify a value for
>TARGET_ENV on the
>> command line. To simplify the command line I created a batch/shell
>> script that accepts the target environment and a set of Ant targets
>> and creates the command line used to invoke Ant.
>>
>> This works fine but I am just not happy with the solution. I have
>> searched the web for solutions others have created for this problem
>> but it doesn't seem to be anything anyone really talks about or I am
>> looking in the wrong places.
>>
>> So what have you done?
>>
>> Samer Kanjo
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For
>additional
>> commands, e-mail: user-help@ant.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For
>additional commands, e-mail: user-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org