I think you are talking about adding a default behavior so that if no
args are passed the production release is created. This can be done by
adding another target like this...
<target name="set.default" unless="env">
<property name="env" value="prod"/>
</target>
Then make the other targets depend on this one. If ${env} is passed in
on the command line, this target will not run, otherwise ${env} will be
set to your chosen default value. Doing this, you will have to be
carefull where you put the <property file="${env}.properties"/> to be
sure that the ${env} property is set.
Another option is to prompt for the value of ${env} on the command line
with the <input> task. Using the input task, you could specify valid
input args and even a default, hopefully reducing the possibility for
someone to screw it up.
Your name looks familiar. Did you used to work at NextCard in SF?
-Rob Anderson
> -----Original Message-----
> From: Ferrer, Eric [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 21, 2006 2:58 PM
> To: Ant Users List
> Subject: RE: Regarding Continous build integration.
>
> 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]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
