ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Ant allegedly becoming a perl
Date Fri, 07 Apr 2000 04:50:42 GMT wrote:

> James Duncan Davidson wrote:
> >
> > Actually, the way that it is going, I see it becoming a perl. Able to do
> too
> > damn much any which way from Tuesday. Something for everyone, but with
> build
> > files that are too cluttered to read by anybody.
> Oooh.  Them there's fighting words.  Let's start by eliminating taskdef.
> That gives people ***WAAAY*** too much flexibility.
> More seriously, lets take a look at three basic parts of ant: the "core",
> the builtin tasks, and individual task attributes.
> The core:
>    Bean properties are still set via introspection from XML attributes.

One of the coolest features.

>    The core now can now processes nested XML entities.  I discussed this
>    one with you personally, and you seemed to think it was a good idea
>    then.  In general, I think that this _reduces_ clutter and _increases_
>    readability.

I'm seeing the need for this on the new taglibs project -- the general scenario
is semi-independent sub-project builds controlled and monitored by a master
script.  I like it.

>    Properties are still defined and referenced as they always were.  For
>    about a month, they were not allowed outside the scope of a target, but
>    that has been restored.  They still can be defined inside the scope of a
>    target which given how they are processed is very confusing.  In other
>    words, this is still as broken as it always has been.

How about moving to the point where <property> is *disallowed* inside a
target?  That will make the way they work much clearer.  (Same for anything
else that takes effect at the time of initial parse, like filter).

>    Init targets are no longer automatically processed.  This seemed to have
>    consensus at the time.

+1.  There's no need for Ant to have any magic targets like this.  If you need
it, that's what "depends" is for.

>    You can plug in your choice of parser.  This clearly should be ditched
>    for jaxp.  In any case, this doesn't contribute to the clutter.


>    Targets now have a condition.  This is debatable, but was added by
>    Stefano for a very simple reason: he had a job he needed to get done and
>    nobody had any better suggestions at the time.

The implementation isn't bad, and it's going to become a much bigger issue for
Tomcat as it grows.  Consider -- what if we wanted to provide a tomcat
implementation of the application environment stuff in Section 9.9 of the
servlet 2.2 spec?  License issues aside, Sam would fly across the country and
wring my neck :-) if I checked in the JNDI binaries.  Now, do we want to throw
hundreds of compile errors if the poor unsuspecting user doesn't have the JNDI
classes in their class path, or do we want to be smart and just build what we

To say nothing of wanting to take advantage of Java2 features like security
policies, or JAAS, if they are there .....

> Built-in tasks:
>    Clearly there are a few more builtin tasks than there were before.
>    Again, taskdef opens Pandora's box, but if moving a few of these tasks
>    to be "optional" would increase harmony on this project, I would gladly
>    do it.  My only criteria is that I believe that the base Ant should be
>    able to build the real projects, so some support for conditional
>    compilation based on the existence of classes in the class path is a
>    requirement.

IMHO, "taskdef" is how you protect the core from turning into PERL !!!!!

With taskdef, we have a strong argument that Ant's core should be limited to
the things that *everybody* needs.  Any project that needs something cute is
more than welcome to add their own taskdefs, ***in their own project source
code***, and not increase the complexity of Ant itself.  Without it, there's
going to be intense pressure to add this new "mission critical" task that's
needed by project XYZ, and you get an unusable mess.

The extremist position would be that Ant shouldn't support *any* optional tasks
in its own project space -- anything not obviously generic is by definition
project specific.  The more moderate position would be to support a
"jakarta-ant-tasks" subproject, to accumulate stuff that people find commonly
useful across projects, but still don't justify being added to the core.  It
might be reasonable for the user to configure some "well known" property that
points at the <taskdef> definitions for a particular build environment -- but
it's so easy to script that I'm not sure it's worth it.

>    Filtering and MatchingTasks are built into many of the common base
>    classes.  I have no objection to the former, and strongly support the
>    latter.
> Individual task attributes:
>    In general, there have been a number of bug fixes and additional
>    options.  I see no sweeping generalization possible to describe the
>    changes.  I would like to know if you have any particular ones that
>    invite your ire.
> = = = = =
> Summary: I believe Ant to be largely unchanged save for some separately
> loadable taskdefs to be built in; some changes which don't increase
> clutter; and a modest support for conditional compilation which represents
> our best idea at the present time.  Please let me know more specifically
> what you find objectionable.
> - Sam Ruby

Craig McClanahan

View raw message