At 02:04 14/6/00 +0200, you wrote: > [About processing of attributes and where to put this] > > PD> I just hate seeing the same two lines or copied methods all > PD> through my code > >We are in the same camp here. I just believe that the common >processing of attributes - like generating file lists from directories >- could be reused by factoring it out into a helper class - like >DirectoryScanner - and delegate to it. > >We more or less agree on this just disagree where to put the >delegation. I'd prefer to do so explicitly in the task while you >prefer to intercept the attribute setting mechanism. Am I right?
essentially thats right ... make the core difficult and tasks simple. >One thing that just comes to my mind is what to do if the meaning of >one attribute changes the outcome of the processing step for another >attribute? I think this can only be done if the processing happens in >the task's init or execute method. I mean something like > ><javac srcdir="..." excludes="testcases/**" /> >if you process srcdir to a file list how would you ensure the Java >files from testcases are omitted? good point ... how often does this occur ? Is it often that the value of one attribute will effect the value of another ? ie Does this happen often enough for it to be an issue ? Or could it be handled as a special case and in those cases that require it make the effort ... hmmm ... I think I may be coming around to your way of thinking ... sorta > PD> unfortunately classpath usually has to happen *before* task is > PD> loaded .. > >Yes, you are right. I guess the right solution is to use a custom >classloader in the Java task (and maybe in Javac) whenever (1) the >classpath is explicitly specified and (2) fork is false. yep thats what I do now ... unfortunately I have to do for 4 seperate tasks and it is fairly difficult to factor out .... so I was hoping to put it in core ... but I guess I have a different approach. You want the core simple and tasks difficult and the core simple while I swing the other way :P ... I guess I can live with that ... > PD> is that input and output get wrapped before each task executes. > >There has been a request to specify the level of logging on a task by >task basis. Equally one could specify the logging output at the task >level - using the projects default output when omitted. These could be >done inside the Task base class. We have yet to see comments from the >commiters on these issues (I'm not a commiter and far from speaking >for Ant development). okays thou I would hate to do logging on a task level. How do you overide it ? If a task explicitly logs using project object then it is easy to redirect it through the standard verbose/quite flags but what about stdout/stderr on tasks executed. I would like to see something like only displaying it when the task fails or verbose flag is ticked .... is that what you mean ???? BTW spec/core.html is dated "Version 0.5 (2000/04/20)" and doesn't seem to contain all I thought it would .. is there a new version or should it be considered a work in progress ?? Cheers, Pete *------------------------------------------------------* | "Nearly all men can stand adversity, but if you want | | to test a man's character, give him power." | | -Abraham Lincoln | *------------------------------------------------------*
