There are a couple of ways to set properties differently for qa and
development environments, etc. that we use for our projects and which you
might find useful.
One is to set up a separate target which has the name of the evironment,
such as qa, devel, prod. In each of these targets, just put the properties
that are specific to that environment.
<target name="qa" description="set up qa specific properties">
<property name="env.name" value="qa"/>
<property name="app.port" value="8080"/>
...
</target>
<target name="devel" description="set up devel specific properties">
<property name="env.name" value="devel"/>
<property name="app.port" value="5050"/>
...
</target>
When you want to execute a target which depends on the environment specific
properties, you just do something like this:
$ ant qa app.build
or
$ ant devel app.build
If you want this to be provided via an environmental variable, one way to
have that happen all the time would be:
$ alias ant='ant $BUILD_TYPE'
As an alternative, or in addition you can add a properties file for each
environment as well:
<target name="devel" description="set up devel specific properties">
<property name="env.name" value="devel"/>
<property name="build.properties"
value="${basedir}/build/environments/${env.name}.properties"/>
<property file="${build.properties}"/>
...
</target>
You can also add user specific properties, which I've found useful:
<property name="user.prefs"
value="${basedir}/build/users/${user.name}.properties"/>
<property file="${user.prefs}"/>
I consider the above approach, which I would describe as table driven logic
to be superior to using conditionals. It looks cleaner to me.
One of the arguments against conditionals, which you will see time and time
again on this and in the ant-dev mailing list, is that they can be abused so
easily, that is, conditionals are used when a simpler, more natural (for
ant) construction can be used instead. Of course this isn't *always* the
case, but it probably is at least 9 times out of 10.
Julian.
> -----Original Message-----
> From: DONNIE HALE [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 20, 2001 7:03 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proper use of <uptodate> (a little off-topic)
>
>
> Aaah. Out of curiousity, and without trying to start a new
> religious war :), could you summarize the reasons for the
> rejection? Or perhaps give me a keyword that will help me hit the
> right archived messages?
>
> The multiple .properties files idea is interesting. A little ugly
> to manage, but the .xml file would be clean as a whistle.
>
> Thanks again,
>
> Donnie
>
>
> >>> [EMAIL PROTECTED] 12/19/01 03:02PM >>>
> --- DONNIE HALE <[EMAIL PROTECTED]> wrote:
> > That makes sense. The only hitch is that my "determining property" is an
> > environment variable. So, as you say, I have to jump through a bunch of
> > <conditional> hoops to turn that into one of several different
> > properties for a <target>'s "if".
> >
> > Might I propose that this would be much simpler if <target> had this
> > construct:
> >
> > <target name="..." depends="..." if="prop.name" equals="prop.value">
> > ...
> > </target>
>
> That you won't get -- it's been proposed many times before, and thoroughly
> rejected each time.
>
> But, as Steve pointed out, using property files is the way to simplify the
> whole thing for you (should've thought of that myself, but brain's not
> working too good with this nasty cold)... So, once you have your props
> files, you'd just need a single target to figure out which file to read in
> and then read that one in. Eg:
>
> <target name="setProps">
> <condition property="propsFile" value="val1.properties">
> <equals arg1="${determining_property}" arg2="val1"/>
> </condition>
> <condition property="propsFile" value="val2.properties">
> <equals arg1="${determining_property} arg2="val2"/>
> </condition>
> ...
> <property file="${propsFile}"/>
> </target>
>
> Diane
>
>
> =====
> ([EMAIL PROTECTED])
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
