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