Re: Ant allegedly becoming a perl

[ru...@us.ibm.com]

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

Re: Ant allegedly becoming a perl

[James Duncan Davidson <ja...@eng.sun.com>]

> Oooh.  Them there's fighting words.  Let's start by eliminating taskdef.
> That gives people ***WAAAY*** too much flexibility.

Yeah! :)

> The core:
>
>    Bean properties are still set via introspection from XML attributes.

Yep. This is the core mechanism by which things operate. The idea was to
have a bean set up for the way Ant operated. XML wasn't supposed to be
central to the beast, just a format that could be used. I still think that
XML as a format is useful, but shouldn't take over everything... The OO
nature of Ant is more important.. Project-->Target-->Task.

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

Yes. Entities in the XML should be resolved and used as is. This is ok.
That's just XML.

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

Yes. Still broken. I really would like to see properties only defined at the
Project level. ie. properties and targets are peers under project.

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

And is good. Special init targets are too ugh.

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

Yes. JAXP is the only way to go.

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

I'm not really liking having conditions on targets. I'm not sure right now
the best way out of this...

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

Yes, Ant should do everything that the JDK can, plus a few things like
copying files, etc. Everything else should be contrib.

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

Properties, and the way the behave really don't sit well with me right now.
Command line defined props *and* system properties should take preference
over any prop defined in the build.xml file.

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

Conditional compilation is something that should be approached and done,
just carefully.

I guess what I'm ired at most is that I didn't give a clean, clear guide to
where I thought Ant should go or what it was designed to do when I put it
out. I'm working on that and hopefully will get it to this list soon.
Without a strong core design doc, things seem to change willy nilly and
features seem to get bolted on. Obviously, this is the way it's going to be
without a design doc, but I'm still grumpy about it. Catch 22.

It's clear that the project-->target-->task level of definition in the XML
wasn't enough. There needs to be a common way for the layers underneath that
to be treated. As much as I'm not into scripting, there needs to be a way
for a scripting task to be plugged in that has access to the runtime.

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

.duncan

Re: Ant allegedly becoming a perl

[James Duncan Davidson <ja...@eng.sun.com>]

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

Actually, instead of entities, I think that I like the:

  <target ....>
     <ant buildfile="foo/bar/build.xml"/>
  </target>

approach to recursion of this sort.

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

This is conditional compilation, not conditions on target execution.
Different things.

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

There also needs to be a way just to have contrib or optional taskdefs
installed into the system so that you dont' have to use taskdef.

.duncan

Re: Ant allegedly becoming a perl

["Craig R. McClanahan" <Cr...@eng.sun.com>]

rubys@us.ibm.com 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.
>

+1.

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

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