Rob, 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 -Eric -----Original Message----- From: Anderson, Rob (Global Trade) [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 3:20 PM To: Ant Users List Subject: RE: Regarding Continous build integration. > -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > 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 ( http://smartfrog.org/ ) to merge deployment and > configuration. (I'm part of this project) > > Properties files just dont scale. > > -steve > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > 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 databaseconnection.properties.template that looks like this... ConnectionString=_ENVConnectionString_ Then you would have a properties file for each environment that looks like this... dev.properties =============== _ENVConnectionString_=jdbc:blahblahblah:host_a qa.properties =============== _ENVConnectionString_=jdbc:blahblahblah:host_b So then in your build.xml you would copy databaseconnection.properties.template to databaseconnection.properties 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
