ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brill Pappin" <john.pap...@jmonkey.com>
Subject RE: Feature
Date Thu, 08 Jun 2000 02:47:09 GMT
I don't know... personally I don't want to spend the time writing support
software so I can check log output... but I could do it very quickly if it
was already built in. (it is) I really like the idea of having a
configurable granularity, and would like to see it implemented...  however,
I don't want to have to wrap every task I wanted to log, in a log task...
instead, turn on logging from a global param (maybe a file name, if its
missing, logging is off), and add a property to the base task class for the
logging level, default to NONE... you could then control not only the
granularity of which task was logged, but also the granularity of the task
log itself.

Maybe 4 levels of log NONE=well, none :), ALL or DEBUG= log everything,
MARKER=the beginning and ending of a task, MESSAGE= the same as what is seen
on the console.

Anyway, this would allow each taskdef to define what was important for each
"mode"... and it would mean minimal change to the structure of Ant, besides
the fact that each taskdef would now need to be able to output messages.

comments? Flames?

- Brill Pappin

> -----Original Message-----
> From: Ken Wood [mailto:kwood@i2.com]
> Sent: June 7, 2000 6:06 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Feature
>
>
>
>
> "Reynolds, Ron" wrote:
> >
> > i also need logging ability, but on a task-level.  having the
> entire build
> > logged to file would just be information-overload.  is there anything to
> > support this granularity of logging?
>
> Well, the problem is always one of where to draw the line.
> I suspect that the Ant developer's primary task ought
> to be issues related to building, not logging...
>
> What our team has always done is filtered. We have builds running
> with full logging, and then a "watch build" program that
> picks out key details from the log and displays it
> as a web page. So, at anytime we can check the status
> of any build by looking at it's web page.
>
> We've also done post build filtering to pick out
> key results and send summary e-mail to developers.
>
> Now, to me, those are "meta-build" tasks, which we the users
> of any build tools should handle ourselves. But, that's just my view....
>
> -ken


Mime
View raw message