ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ferrer, Eric" <>
Subject RE: Regarding Continous build integration.
Date Tue, 21 Feb 2006 22:58:02 GMT

Is there anyway to do what you described all at once with out providing
the arguments?  

For example, I want to provide 3 targets (build all, build with unit
testing, build static content only)

I would then like to generate a war file for dev, test, and prod with
appropriate properties file in them in one pass.  I guess I am looking
for the best practice approach.  Currently I control the builds on dev,
but test and prod will be done by third party vendors.  I would like to
prevent them from having to pass different arguments as I know that one
day they will mess it up and deploy the wrong thing.  This would lead to
me having to figure out that they are connecting in production to a dev
database using dev config throughout the system.

Thanks in advance

-----Original Message-----
From: Anderson, Rob (Global Trade) [] 
Sent: Tuesday, February 21, 2006 3:20 PM
To: Ant Users List
Subject: RE: Regarding Continous build integration.


> -----Original Message-----
> From: Steve Loughran [] 
> Sent: Saturday, February 18, 2006 2:24 PM
> To: Ant Users List
> Subject: Re: Regarding Continous build integration.
> Ferrer, Eric wrote:
> > This topic brings up an interesting issue I am having and maybe the 
> > community has the answer.  I have a local build for tomcat and our 
> > development environment (properties files are the same, 
> information to 
> > connect to our databases the same).  However, the problem lies with 
> > deploying to JBOSS our QA environment and our Websphere QA 
> environment.
> > The wars from the dev build after validated either get 
> moved over and 
> > then the QA environment is talking to dev database, or after moving 
> > the war, the properties files are migrated over that point 
> to test and 
> > the war is rebuilt.  (QA is out of my control)
> > 
> > I feel there has to be a better way to deploy across application 
> > servers and/or at least be able to fun a build for dev, 
> test, and prod 
> > that use the appropriate properties files for each 
> environment in the war.
> > 
> oh yes. but its complex, currently complex enough that only 
> once you have tens of machines do people bother to automate it.
> the problem is really the difference in configuration between 
> systems stops you just moving things around.
> -have a different properties file for each hostname,
> -use LDAP to configure every cluster
> -use smartfrog ( ) to merge deployment and 
> configuration. (I'm part of this project)
> Properties files just dont scale.
> -steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Using different properties files for each hostname or environment is a
good idea. I have had great success in the past with using the <replace>
task combined with an environment or host specific properties file and a
template that is used to generate the actual config files that get
deployed. So for example, you may have a file called that looks like this...


Then you would have a properties file for each environment that looks
like this...

So then in your build.xml you would copy to
and use the replace task to populate the ConnectionString property with
the correct value for the environment. Run Ant with the following
command to pass in the environment as a property.

ant -Denv=dev

Then in your build.xml you would have something that loads the
properties from the right file...

<property file="${env}.properties"/>

I the case where you are using different servlet engines, you may need
to use a completely different set of properties files. You may just
decide to version a set of config files for each environment with the
correct values already populated. Then simply use the ${env} property to
decide where to find the config files to include in your app.

-Rob Anderson

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message