Peter, I re-read your reply and I was confused as to what you were stating.
I think I have it straight now. You are claiming that by moving the fetching
of properties into an engine.getProperty(name) method, this is making it too
difficult for the Task developers.

I am receptive to this as an issue. I would propose that reflection be used
before calling Task.execute() to populate the appropriately named setters.
This should take care of that issue, no?

jim

> -----Original Message-----
> From: James Cook [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 15, 2001 8:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Ant 2.0 - Frantic: How are properties resolved?
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:[EMAIL PROTECTED]
> > Thats what I thought - I am completely and utterly -1 on this aspect.
> > Mainly as it becomes so hard to maintain and requires heaps of extra
> > programming in 90% of the cases. (It is useful in some
> instances but....)
> > It should be the containers responsibility rather than components. The
> > reason is that moves all complexity to us and leaves task writers with a
> > cake walk ;)
>
> Please elaborate. As far as putting more complexity on us (Ant design), I
> don't see it. In fact, the code that exists now fully supports complex
> property substitution. What is the issue?
>
> > >The HierarchialHashtables are a means of storing property values
> > in a scoped
> > >manner, but they go ahead and store properties in their ${}
> > form. When the
> > >property is requested by the Task, it is substituted at that time.
> >
> > Yep - so you have two object trees - the real object tree and the proxy
> > object tree ?
>
> When the program starts, all I have is an object tree. As Tasks
> get executed
> and nesting levels ensue, I build a property tree that represents the
> runtime structure of the build process. You need two trees because the
> static view (the XML file) does not equal the runtime view. The
> runtime view
> can jump all over the place in a manner that is not reflected by the task
> hierarchy.
>
> jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to