Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38F3543F.9152AEE8@eng.sun.com>
Date: Tue, 11 Apr 2000 09:35:12 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Ant allegedly becoming a perl
References: <852568BE.000D6A76.00@d54mta04.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A few embedded comments below.

rubys@us.ibm.com wrote:

> .duncan wrote:
>
> -  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.
>

The idea of "building big things out of little things" is certainly not new.
Makefiles that execute nested makefiles seem to be the norm on large C/C++ code
bases like Apache, or PostgreSQL.

Wild idea:  One of the reasons I found myself using properties is that you
cannot conveniently access the attributes of your surrounding object (i.e.
tasks cannot see the attributes that were set on the <target> you are nested
inside).  Conceptually, I suppose, you ought to be able to work your way up the
object tree to the <project> object.  Now, everything could be attributes
instead of properties.  This is not too different from the environment that JSP
custom tags see at runtime, where you can work your way up a tree of nested
page contexts.


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

+1, but ...

In general, properties or attributes set in "outer" contexts should override
properties set in "inner" contexts, in some easily understood and predictable
manner.  But what about the case where you want to establish a default value
(like the setting for the deprecation flag on compiles) but *allow* overrides
inside?  Two kinds of properties?  (Yuck).  Reverse the hierarchy so that
"inner" overrides "outer"?  (You can get yourself in trouble by overriding the
wrong things.)

Note that "make" follows the latter path -- inner properties override outer.
But it also provides conditionals so that you can do this, for example, only if
no outer value was declared.

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

I agree that conditional compilation is a core requirement.  The challenge is
to decide the kinds of things it should be conditional on.

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

So here's a couple possible sparks.

>
> - Sam Ruby

Craig McClanahan