ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <james.david...@eng.sun.com>
Subject Re: Ant allegedly becoming a perl
Date Tue, 11 Apr 2000 01:22:07 GMT
> 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


Mime
View raw message