> From: James Duncan Davidson [mailto:[EMAIL PROTECTED] > > > On 12/19/00 12:16 PM, "James Cook" <[EMAIL PROTECTED]> wrote: > > > I hate to sound like I'm a whiny child here, but you guys > should really read > > my proposal before you start thinking about implementation > specifics like > > workspace/module. > > I have. You state that the one of the reasons for treating > everything as a > task is for efficiency. And you note that Ant spends cycles > analyzing the > dependencies between targets. I think you over stress the > impact of these on > performance. In fact, in a typical build of even a small > project of 10 or so > class files -- Ant spends so little of its time in the setup > necessary to > assemble the project tree *and* analyze dependencies that > this is not worth > optimizing out. Almost all time is spent in the compiler or > in other tasks > -- the impact of which is beyond the control of the core. >
To say a work on James behalf, One thing that is true in ANT 1.2 is that certain element names are hardcoded in the ContentHandler for example: <target>, <property>, <taskdef> and everything else at project level is lokked in the data-type table. So for example, if I where to define some <aliasdef> to define some sort of templates of commonly used tasks, I would have to go and change the Content Handler. Instead, an approach like James wold define everything as task in one namespace, and we would have a richer set of interfaces for tasks that describe whether they are allowed at Project, or target level or both. I have no idea is James' proposal goes that way, since as many other there is no way for me to go through all these proposals. > As interesting as it is to view the world as a tree of single > type nodes, > when you get into using things for long its inevitable that > some sort of > specialization creeps in somewhere. And its actually quite > useful at times. > Genericity is not necessarily your friend. Yes, this is a > biased opinion -- > it's based on 3 1/2 years of coding Java at JavaSoft though > if that means > anything. > To me actually, the thing I am not clear with respect to James proposal is how the sorting or <targets> is to be acomplish in this world of tasks. So we have the Project, a task, that gets executed. But here we do not want to just execute arbitrarily, but to execute certain targets. Moreover, something needs to do the sorting of the targets. Do targets will register their dependencies themselves of is this part of the the job of the Project. Do the Project really treats <properties>, <data-types> and <targets> all the same way when using this abstraction? As I said, I do not have the time to get into the code, but would like to know. Jose Alberto
