>>>>> "PD" == Peter Donald <[EMAIL PROTECTED]> writes:
PD> At 12:55 14/6/00 +0200, you wrote: >> The way to go for attributes (IIRC) was to use classes with a >> constructor taking a String object as its only argument. PD> okay ... sounds good for user created types but how about PD> standard types in java library .. File and URL have String constructors as well as say Integer. For File you might want to use resolveFile before calling the constructor or use a subclass of File that resolves the File itself. Special cases for the primitive types have been considered - although I can't remember whether they were accepted or dropped in favor of the wrapper classes from java.lang. [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? 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? 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. 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). Stefan
