ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject Re: Getting the filename from a property
Date Thu, 28 Feb 2002 07:48:14 GMT
--- Erik Hatcher <> wrote:
> > Okay, this at least says something. The "{0}" is a little obscure
> Obscure?  Huh?  Ant has ${...} all over the place.  How is that at all
> obscure to you?  :)

I said: "...but not any more so than...", and by that I meant that, by
itself, it doesn't read as anything -- but, again, not any more so than...

> <property name="basename" value="${property,file,basename}"/>
> That ok to you?

Actually, I'd prefer to just have tasks do the job, since that seems more
in line with "the Ant way" than the above does. 

> The goal, at least for most of us Ant committers, is to move Ant further
> away from being a "scripting" language and more into being declarative
> in Java-speak.

Well, I guess I must have a very different perspective, because that looks
really "scripty" to me, so to me, that seems like it would be moving Ant
more towards being a "'scripting' language".

> You are coming at Ant from a far different perspective than the rest of
> the committers, mostly, from what I can tell.

You think? In what ways? (Just curious.)

> Thats not a bad thing.

Well, it's not even been established yet as necessarily a true thing, so
you may be jumping the gun a bit on adjudging it bad or good.

> But Ant should not, IMHO, be programmed like bash or JavaScript

It not only shouldn't be -- it can't be, since it's not a programming
language. See, here's the difference, apparently, in my take versus yours
on the <script> task. To me, it's just another task, and doesn't have
anything to do with Ant itself being "scripty". Whatever's in the script
within the <script> task, to me, isn't any different than what goes
inside, say, a <javadoc> task or an <ejbjar> -- those have attribute and
nested elements (some tasks have them out the wazoo, and can get
exceedingly "convoluted and wacky" :), and the <script> task has script
text. But that doesn't make, or even contribute to making, Ant itself a
"'scripting' language".

> I just think the current way of scripting is too "low level", down to
> the "metal".  We should be "scripting" at a higher level in the Java
> domain-speak.  Does that at all make sense?

Not really, sorry. I don't particularly like can't-get-there-from-here
type things (which is one reason I sometimes get frustrated trying to deal
with Java). I know there's sometimes this tendency on the part of the Ant
developers to "protect" people from shooting themselves in the foot
(Stefan recently posted a concern about people's shell-scripting
capabilities, at my suggestion to allow for an additional .antrc -- but,
really, there's nothing to stop them from doing that now in their $HOME
one, or even in the 'ant' script itself, so I think the concern is a bit
misplaced). But at some point, if you get too overly protective, you'll
just frustrate the people who do know what they're doing, when they go to
do something they really need to do only to find out they just can't do it
(without just basically making their own in-house version). And with
things like <script>, I think most of the people who do use it either know
what they're doing, or take a very cautious approach to it if they're not
entirely certain they do.

> I understand where you are coming from, I really do.  (hey, I've written
> my share of .sh/.pl/AWK/SED scripts, as well as tons of JavaScript).

I only ever offer a <script> task when there's no other option -- that's
why I -like- having that option available. You can't just say to everyone,
"Write a task" -- not everyone who uses Ant as a build tool necessarily
even knows Java (or at least well enough to write a new task). You seem to
think my buildfiles are nothing but <script> task after <script> task, but
in fact, I don't think I've ever even used one in a production buildfile.

> Again, I believe our mission here, at least mine, is to elevate Ant
> to "speak" closer to our problem domain, that of building Java
> projects.  Surely you can't argue with that sentiment, can you?

Well, gosh, no. But I also think offering a <basename> and <dirname> task
would be the most "Ant way" of dealing with this -- more so than having
<property> do parameter substitution.



Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

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

View raw message