In addition to backwards compatibility, there are other issues to consider:
1) Granularity: why limit timing data to targets? why not extend it to tasks as well?
2) Filtering: do you want timing data for every target? every task?
and the big one....
3) Multithreading: as the committers on this list will tell you, I'm always thinking about this one. At IBM, we use Ant + in-house antlibs to build the WebSphere family of products. We're fortunate to have very good hardware in our build lab, and with products as large as WebSphere we're keen on making the most efficient use of it; one of the ways we do that is to multithread our builds. In our initial experiments we wanted to get timing data to compare against our single-threaded builds, so we wrote our own custom logger (just slight changes to the default logger) to print the timings. When we ran the builds, everything went haywire.
The upshot is that we had to write our own logger from scratch to meet our needs for running in a multithreaded environment. I know that most people don't do this, but I don't think we should be introducing code into Ant that we KNOW doesn't work in certain cases.
JEC
| ____________________________________________________________________________________________ | |
| Jeffrey E. (Jeff) Care | |
| IBM WebSphere Application Server Development |
WAS Pyxis Lead
Release Engineer
|
|
| |
Paul Hammant <[EMAIL PROTECTED]> wrote on 08/18/2006 06:25:20 AM:
> Without any cited cases I am prepared to believe that someone is
> programatically processing default log output in such a way that it
> would break if it found one of..
>
> compile @ 1 minute 12 seconds:
>
> compile (1 minute 12 seconds):
>
> compile:
> (at 1 minute 12 seconds)
>
> .. and that it would be too much for that team to fix their
> application to accommodate the new info.
>
> Perhaps an ant.exe command line switch could do it ( -timedTargets )
> or an environmental variable ( -DtimedTargets=true )
>
> Bugzilla bug 27771 is in the same realm too - http://
> issues.apache.org/bugzilla/show_bug.cgi?id=27771 and hints that an
> additional temporal element to the Default Logger output would be
> problematic.
>
> - Paul
>
>
> On Aug 14, 2006, at 4:58 AM, Jeffrey E Care wrote:
>
> >
> > I wouldn't make the assumption that ALL automated log analyzers use
> > the XML format.
> > ______________________________________________________________________
> > ______________________
> > Jeffrey E. (Jeff) Care
> > [EMAIL PROTECTED]
> > IBM WebSphere Application Server Development
> > WAS Pyxis Lead Release Engineer
> >
> >
> >
> >
> >
> > "Paul Hammant" <[EMAIL PROTECTED]> wrote on 08/11/2006 04:34:21 PM:
> >
> > >
> > > Alexey,
> > >
> > > > This one works: dir ham.txt>output.log 2>&1
> > >
> > > ant [target] >output.log 2>&1
> > >
> > > .. works well.
> > >
> > > Tis up to you guys to change the DefaultLogger or not. It sure looks
> > > nice when you run it and there's no harm as electronic processors of
> > > Ant output (like CruiseControl) use the XML logger.
> > >
> > > - Paul
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
>
