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 Thu, 28 Feb 2002 09:48:52 GMT
From: "Diane Holt" <>
> > 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".

I think the differences we are having are in how we interpret what a
"property" is.

Currently a property is just a string (java.lang.String under the hood).
What I'm saying is that Ant's power is all about its rich data type
abstractions (<path>, <fileset>, etc).

Your examples are working within what you've been given with the current
version of Ant, and you are dealing with a "file" as if its a string, and
ripping out pieces of it via <script> or making <pathconvert> do the dirty
work. What I'm getting at is that we should be dealing with a "file" as if
its a file (simplistically a, but more realistically through
Adam's VFS stuff). So when you've got a "file" you can get its component
pieces by just asking for them.  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.  Its not scripty to ask <tstamp>
for a date in a particular format - just a different visual representation
of the same underlying thing.

A lot of this is philosophical and theoretical, as its meaningless without
some implementation out there, but again my goal is to push Ant in the
direction of dealing with Java concepts natively as datatypes.  The package
name thing is a prime example.  Why shouldn't Ant be able to easily handle a
package name handed to it?  The "scripty" stuff to turn it from
dotted-syntax to path syntax within appropriate contexts should be automatic
and implicit rather than doing some kind of string.replace('.','/') kinda
thing (yes, that would be going on under the hood, of course).

> > 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.)

You're without a doubt a Unix shell scripting wiz.  I was once upon a time
too - still got my copies of The Unix Programming Environment (hardback!),
The Awk Programming Language, and the infamous Perl camel book.  I love that
stuff!  There is nothing finer than the backtick tricks to inject things
into places that mere mortals cannot comprehend!  :)  And you're not a Java
programmer by day like most of the rest of us (self-confessed).  Hey, I'll
be the first to say that you ROCK! as an Ant committer.  We could not
survive without you.  Your unique perspectives keep us on our toes and your
documentation and Ant skills are dead on.  We're all coming at this from
different perspectives and backgrounds.

> > 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>

Agreed.  I want <script> to be just like a task.  And Conor's <scriptdef> is

Again, see above, my point is that some of the ways currently to accomplish
something are done the "hard way" because Ant isn't representing the problem
domain well enough.  Its our job to get those representations right so that
a build file reads like someone telling you the steps of the build process
(and someone would not tell you, typically, that you gotta replace dots with
forward-slashes when describing how to build and deploy a J2EE application!

Am I clearing this up any?

> -- those have attribute and
> nested elements (some tasks have them out the wazoo, and can get
> exceedingly "convoluted and wacky" :)

You won't get any argument from me there.  <javadoc> is horrendous!

<ejbjar>'s dilemma is that really only one committer has worked on it
actively.  It could easily be refactored to be more extensible even given
the more static nature of subelements of a task.

> > 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

I'm not quite of the "protect" the user vein that you speak of (I submitted
the DynamicConfigurator patch that got vetoed afterall!).  I'm more of the
lets-speak-a-higher-level-language vein rather than doing workarounds
because Ant ain't speaking the right language.

> 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).

Exactly!  And those same people that can't write a new task shouldn't be
writing <script> either since they are essentially the same thing (even in
your own words).

And I agree with you, when there is no other option, its time to hack and
make do with whats there - not any argument there.  We should just learn
from these things that Ant is not doing its job fully if you have to resort
to that.  And I do not at all propose taking away that capability either -
just making Ant more intuitive and closer to the problem domain.

> 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.

Excellent!  Neither have I - and I've patched <script> to be easier to use
(no more need to know your Project name to get to things).

And no, I did not think that about your build files.

> 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.

The current Ant way, yes.  But the Ant2 way will be much better, me thinks!

    Erik - who's days and nights have somehow flip-flopped

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

View raw message