ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [RFE] Richer Task Specification
Date Wed, 14 Jun 2000 14:08:34 GMT
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 ??


| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message