Return-Path: 
 <ant-user-return-15607-qmlist-jakarta-archive-ant-user=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@apache.org
Received: (qmail 59075 invoked from network); 21 Dec 2001 09:22:50 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 21 Dec 2001 09:22:50 -0000
Received: (qmail 13739 invoked by uid 97); 21 Dec 2001 09:22:51 -0000
Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org
Received: (qmail 13723 invoked by uid 97); 21 Dec 2001 09:22:50 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Id: "Ant Users List" <ant-user.jakarta.apache.org>
Reply-To: "Ant Users List" <ant-user@jakarta.apache.org>
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 13712 invoked from network); 21 Dec 2001 09:22:50 -0000
From: "Julian M. Savage" <jsavage@fisci.com>
To: "Ant Users List" <ant-user@jakarta.apache.org>
Subject: RE: Proper use of <uptodate> (a little off-topic)
Date: Fri, 21 Dec 2001 18:22:27 +0900
Message-ID: <NFBBKGAKOKCKALNEAAFMCEKDEIAA.jsavage@fisci.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <sc20c82e.056@GW_SRV.corp.longaberger.com>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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:DHALE@longaberger.com]
> Sent: Thursday, December 20, 2001 7:03 AM
> To: ant-user@jakarta.apache.org
> 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
>
>
> >>> holtdl@yahoo.com 12/19/01 03:02PM >>>
> --- DONNIE HALE <DHALE@longaberger.com> 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
>
>
> =====
> (holtdl@yahoo.com)
>
>
>
> __________________________________________________
> 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:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>