ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: [RFE] Richer Task Specification
Date Wed, 14 Jun 2000 12:04:41 GMT
>>>>> "PD" == Peter Donald <donaldp@mad.scientist.com> 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

Mime
View raw message