Return-Path: 
 <ant-user-return-15042-qmlist-jakarta-archive-ant-user=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@apache.org
Received: (qmail 1262 invoked from network); 4 Dec 2001 19:20:06 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 4 Dec 2001 19:20:06 -0000
Received: (qmail 28965 invoked by uid 97); 4 Dec 2001 19:19:05 -0000
Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org
Received: (qmail 28888 invoked by uid 97); 4 Dec 2001 19:19:04 -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 28846 invoked from network); 4 Dec 2001 19:19:03 -0000
X-Originating-IP: [161.69.211.200]
From: "Russ Fink" <russfink@hotmail.com>
To: ant-user@jakarta.apache.org
Bcc: 
Subject: Re: newbie - if-then-else task?
Date: Tue, 04 Dec 2001 19:19:02 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F106bF1kUDMLx0ryCtZ000065fa@hotmail.com>
X-OriginalArrivalTime: 04 Dec 2001 19:19:03.0274 (UTC)
 FILETIME=[88D8FCA0:01C17CF8]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

I tried the other way, using depends and targets.  It is REALLY long, not 
succinct, and IMHO can lead to severe maintenance problems in the long run - 
therefore, I advocate leaving the "available" tag just the way it is.

To do what I wanted using depends and targets, it roughly works like this 
(without too much correctness on the syntactical details):

<<< start of code >>>

// This sets a property, localfile.exists=true, if the file
// exists locally
<target name="check.local">
  <available file="my_local_path/file" property="localfile.exists"/>
</target>

// This calls the target that sets localfile.exists, then
// if localfile.exists is true, it copies the file from the local
// spot.
<target name="copy.from.local" depends="check.local"
       if="localfile.exists">
  // copy from my_local_path/file to my_destination_dir
</target>

// In the event that a local file does not exist, this target
// goes to a system directory and fetches the file there.
<target name="copy.from.system" depends="check.local"
       unless="localfile.exists">
  // copy from my_system_path/file to my_destination_dir
</target>

// We need a dummy target to exercise the depends line and force
// needed copying to occur.  Try copying from local first, then
// try copying from the system.
<target name="copyfile" depends="copy.from.local, copy.from.system"/>


<<< end of code >>>

This I believe is what you mean by the "depends/unless" method.  If so, this 
is verbose, and prone to maintenance error.  For instance, I have to 
maintain a copy of the local file in two separate tags.  Also, where do I 
set a property that tells what file I want to copy?  I would have 
potentially hundreds of files I want to copy, and it would be insane to have 
hundreds of targets, one per file.  What would I do?  I might end up setting 
a property, "file.from", and then have to override it when I want to copy a 
different file - but that would run against the idea of having set-once (is 
this what is meant by 'immutable?') properties.

Now that I'm standing on a soapbox, I would like to point out that if we 
wish to have a suitable build system replacement for Make, then it should 
support at least a basis vector of functionality from Make, to include among 
other things the ability to easily make choices at compile time depending on 
environment variables, tag names, and so on.

Digging in deeper, I strongly suggest supporting in-line Java calls, in the 
form of an XML tag, that would be similar to how Make supports "in-line" 
shell script constructs (how Make executes shell code... well, that's all it 
does, actually).  This would give some power to the build process, and 
should be fairly easy to implement - just compile all the inline java first, 
then include these classes in the VM when invoking ant.  This would give me 
powerful file copying capabilities, decision making, pattern replacement, 
user-interface prompts (popup dialog boxes), string manipulation, and more.

At least leave the <available> tag the way it is.  Thanks for your help,
Russ

> > Okay - I think I understand.  If I have 'dirs.orig' pointing to the
> > global area, and dirs.local pointing to the local modified area, and
> > want to put the file into 'dest', I can do the following:
> >
> > <property name="frompath" value="${dirs.orig}/foo"/>
> > <available file="${dirs.local}/foo" property="frompath"
> >            value="${dirs.local}/foo"/>
> > <copy file="${frompath}" todir="${dirs.base}/dest"/>
>
>I thought for sure Erik would reply to this, since it's using <available>
>in the very way he's currently trying to disallow, but...
>
>Anyway, yes, you -could- do it this way, but only because <available>
>allowed resetting the value of a property, which (according to Ant's
>"immutable properties" stance) it shouldn't really have been doing, and
>will now bark at you should you try to use it this way (and may well at
>some point not allow it at all).
>
> > (This is still a little more work than I indended, [...]
>
>Well, Ant is exactly known for being all that succinct :)  And if you
>think the above is a bit roundabout, you'll probably be not at all fond of
>how you should really be doing it, which would involve several targets,
>using "depends" and "unless".
>
>Diane
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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