Jeffrey E Care wrote:
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.
+1
I'm all for logging time data, and I have switched to using the logger
of ant1.7 that prints out when a build finished. But any change to the
log can break things. Even adding the time of build success/failure was
enough to break luntbuild, that was looking for a string as well as an
exit code.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
