ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Ant allegedly becoming a perl
Date Tue, 11 Apr 2000 02:20:46 GMT


.duncan wrote:

>Properties, and the way the behave really don't sit well with me right
now.

I took a pass about a week ago at eliminating properties all together.  You
heard me right - eliminating them.  I think that they are way too
procedural.  You don't have them in HTML (except in scripts).
Unfortunately, I gave up.

I started by looking into _why_ they were used (as opposed to how).

-  Some properties were used to modify behavior: build.compiler, debug,
optimize, etc.  Something akin to a css stylesheet would be more to the
point here.  At the top, define a style that applies to all javac tasks -
direct and to the point, as opposed to a procedural.  By allowing an id on
any element (something I've already laid the groundwork for), you could
also allow individual overrides at the attribute level on any element.
Very powerful stuff for projects which invoke other projects.  Watching
where Craig is going with jakarta-taglibs, he is heading towards building a
larger building blocks to be used in the build process.

-  Paths.  More specifically the root or something to prepend.  If we
modeled paths as containing two or more parts, and allowed some form of
XPATH (e.g., directly express that you want to use the output of the
previous javac task as the input to the jar process as opposed to
coincidentally mentioning the same string in both places).  Unfortunately,
which the resulting data model is considerably better from a capturing the
intent point of view, it quite frankly sucks from a usability point of
view.

-  Availability flags.  This is part of the "evil" conditionals described
below.

-  Miscellaneous.  Project names, versions, timestamps, and the like.  I
never got here as I gave up on paths, but my feeling was that if we could
come up with something better for the above cases, perhaps we could leave
these as properties for now...

>Command line defined props *and* system properties should take preference
>over any prop defined in the build.xml file.

I agree.  And properties passed from a parent project should override the
properties in a subproject.  There are bugs in this area - I can't override
dist.dir in jakarta-taglibs for example and have it still take effect in
jspspec.

>Conditionals in the targets are not clear and clean. bleck. Targets should
>just be able to define dependancies with the logic in the tasks (even if
the
>logic is defined with script instead of a class).

Much as I like scripts, I want to resist making them *required* as long as
humanly possible.  And I view conditional compilation as a necessary core
requirement.  At the moment, I feel that optional excludes are less evil
than optional tasks (contrast ant's build.xml to cocoon's).

>So, really I need to shut up and put together that document and then there
>will be a exposition of what I think and then people can either use it or
>not. :)

I'm actually thinking that if each of us puts down some random thoughts
(like the ones I just put down above), it might spark an idea that catches
on.  Then again, probably not.

- Sam Ruby



Mime
View raw message