ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Haas" <>
Subject Re: Ant Principles
Date Wed, 19 Apr 2000 19:43:57 GMT

> > Therefor at least the core components should be build in a reusable way
> > the object model Project<-1--*-Task may be extended  to
> > Project<-1--*-Task-1---*>Task (UML in simple ASCII is not easy - I hope
> > get the idea).
> So, you're saying that tasks should be able to hold multiple other
> tasks? As I said in another email, I'm not sure about this... I think
> that taking the reflection tree down in just pure object sense (and
> leaving tasks as a single layer ordered list) makes the most sense to me
> right now. But maybe I misread the UML. ;)

It is not the UML you misread, I was unclear. Sorry.
If an object implementing some task can use other objects, we do not  need
to split the function part and the beans/reflectable part of tasks into two
objects. Today this is not possible, because task A using task B cannot set
the project variable,  as it is private. To allow reuse, either split the
task object into one implementing the functionality and one that gets
reflected in and uses the other - OR allow tasks instantiate other task (and
setting the project instance variable). If the second is preferabkle to the
first, make it a general principal, that a task being executed may either be
reflected in or created by another task, which was reflected in.

Hope, I am clear this time -- let me know, if not.

> > We already preinstall ANT on all our dev machines. I would like to have
> > built time option to include optional stuff into the ant which gets
> > installed. I do not think this is an issue, I simply would like
> > extensibility not only at run time using some sophisticated installation
> > procedure, but also at build time.
> Right. Noted. Is it acceptable for the optional tasks to be in the
> directory hierarchy of the distribution?

I still prefer a single jar holding our ant distrubution, but your
suggestion is fine as well.

> > YES for common internal representation. As others pointed out, a common
> > external representation is too much.
> > I would even suggest to use the URL object as representation of
> So, you'd prefer to see file://foo/bar? That's pretty much what foo/bar
> would be. Hmmm.
> > For extensibility objects manipulation file content should offer a
> > based interface, to allow integration of resources provided by FTP or
> > servers or database (YES, we are working on this).

Arrgh. I deeply regret not having written "URL object as INTERNAL
representation of resources" - meaning objects (being either tasks or
"functional" objects) dealing with resources, should use an URL
representation, whenever possible. Objects manipulating resources should use
InputStream and OutputStream for their interfaces. To allow good reuse.

- tom

View raw message