ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DONNIE HALE" <DH...@longaberger.com>
Subject RE: Proper use of <uptodate> (a little off-topic)
Date Fri, 21 Dec 2001 14:28:16 GMT
Thanks for the feedback.

I'm doing a little of what you're suggesting at present, based on our ENVTYPE environment
variable. So far that's working nicely where the value turns directly into a suffix on a file,
e.g. runtime-${ENVTYPE}.properties can be put in a jar with the expected name runtime.properties.

For your approach to be most useful, it would be terrific if I could ***write*** a property
file from ant. That would let me have the build.xml file be the sole owner of port assignments,
etc.; and they would get stuffed into the various property files needed by the application
when the archives are built. Something like:

<propfile name="env.properties" append="true">
  <include property="app.port" />
  <include prefix="app.prop." />
</propfile>

where the prefix attribute means any property ant knows about beginning with the specified
value gets written to the property file.

I don't want to have to go to 3 different property files and a .xml file, etc., when I have
to adjust ports or whatever.

Thanks again,

Donnie

>>> jsavage@fisci.com 12/21/01 04:22AM >>>
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>


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


Mime
View raw message