ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject Re: ANT's strange semantics and proposed change
Date Fri, 25 Feb 2000 16:51:07 GMT


--On Fri, Feb 25, 2000 12:30 PM +0000 Ludovic Claude
<lc@websitewatchers.com> wrote:

> William Uther wrote:
> 
>> I suggest a new way of handling things:
>> 
>> ProjectHelper only instantiates targets.  Each target simply holds a
>> pointer to its DOM object without actually building all the tasks.
>> 
>> When a target is executed it builds the enclosed tasks one at a time,
>> sets their attributes and executes them.  Because each task is created,
>> set and executed in order there is no reason to have an init() method
>> where properties are set.  They can be set in the execute() method and
>> they will change the attributes of future tasks.
>> 
>> Thoughts, comments?
>> 
>> \x/ill            :-}
> 
> It definitely looks like the way to go. The only problem is that you
> induce a dependency
> between Target and the DOM.

Yeah, I started thinking about this in more detail last night.  I was
actually thinking of putting the code in Task rather than Target.  It has
to work with sub-tasks after all :).

> It would be better to abstract the way ant
> gets its configuration

I think that is the way the current system came about.  ANT currently
builds a hierarchy of objects that parallels the DOM, but is ANT-specific.
Those objects are the Target, Task and createXxxxx objects.  In order to
make the interface for new tasks easy, ANT processes properties during
creation.  This way you don't need two sets of setXxxx methods, one before
processing and one after.  It is this that introduces the strange semantics.

If you delay the processing of properties then you must store the
unprocessed arguments somewhere.  You can either keep them in the DOM, or
you can make another intermediate layer between the DOM and the task
hierarchy.  You then have to expose this intermediate layer.  I don't see
what this buys you over just exposing the DOM.

> by using the Configuration interface defined in the Avalon project
> (another apache project),
> and use their xml loader. The good thing it that it already use SAX,
> which give better report
> on xml parsing errors.
> And also it would bring some people to have a look at Avalon, which is a
> good project but
> looks a little bit dead at present...

Do you have a URL for that?  I searched the apache website and couldn't
find it.

later,

\x/ill            :-}



Mime
View raw message