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 Fri, 07 Apr 2000 01:39:22 GMT


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.

   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.

   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.

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

   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.

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.

   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



Mime
View raw message