> > Therefor at least the core components should be build in a reusable way or > > the object model Project<-1--*-Task may be extended to > > Project<-1--*-Task-1---*>Task (UML in simple ASCII is not easy - I hope you > > 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 a > > 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 resources. > > 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 stream > > based interface, to allow integration of resources provided by FTP or HTTP > > 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
