ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Getting the filename from a property
Date Sat, 02 Mar 2002 02:26:48 GMT
----- Original Message -----
From: "Diane Holt" <>

> > My blue-sky syntax, ${property,file,basename} is not scripty really,
> > its saying that the underlying type of property is really and truly a
> > file and just "formatting" the output as the base name, for example.
> But it seems more scripty to me than current Ant lingo, since it doesn't
> spell anything out.

You and I have far different definitions of "scripty" then.  Spelling it
out, to me, is "scripty" in that you have to manually write all the petty
little details to get the basename - search for the last file separator,
strip from there forward, etc.  Writing explicit steps (i.e.
non-declarative) for routine things is what Ant is trying to avoid.
Otherwise we'd all be writing .sh scripts for our builds!  :)

> One thing you can definitely say about Ant is that
> it's anything but terse -- ask anyone who's ever put together three
> different targets because they can't say <target if="foo=bar" .../>

With <condition> its not necessary to have as convoluted stuff any more.

> But it's the very "visual representation" that makes yours seem scripty
> (for Ant). I mean, if you want to make <property> more of a work-horse,
> and have it deal with things like being told, eg., "consider this property
> I'm derefencing as type 'file', retrieve its basename, and apply it as the
> value of this new property I'm defining", that's okay -- but in order to
> keep that functionality in line with how Ant currently goes about
> representing that sort of thing, it seems to me it should be done with
> attributes and nested elements.

Now you're getting warmer!  But I'm not suggesting any such addition to
<property> - it does enough as it is.  I'm actually not even proposing any
implementation at this time... simply arguing that Ant should be cleaner
than the kinds of workarounds it took (past tense now that you're adding
those two new tasks!) to get such obviously important things like pieces of
a filename.

> > Agreed.  I want <script> to be just like a task.
> What is it you think it currently is? I've never seen it as anything else.

Well, Conor's version is what I'm talking about.  The current <script>
cannot take nested filesets, nor can it accept attributes like a "real" task
can.  So while <script> itself is technically a task, the code you write
inside of it is not the same as what you'd write inside execute() of a Java


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message