Jeffrey E Care wrote:
I know I'm a little late to this party - I've been tied up in my new
assignment. Anyway, FWIW here's my opinion:
I've been thinking about how we could improve our diagnostics, by moving
more of the diags into tasks themselves. Every task could have a
diagnostics(PrintStream) method that would be called to do the diags.
Sounds like a good idea to me; might I suggest that we add a similar
capability for an entire antlib (more on this below)?
1. we could introspect for a public static void diagnostics(PrintStream)
throws BuildException method. This would let us diagnose even if you
cannot instantiate the task enough for new() to work.
I'm a little rusty on static method overrides...if A extends B, can both A
and B have a static method with identical signatures? This should be easy
to test, but I'm feeling lazy at the moment :)
Yes, because static stuff gets set up at compile time (they are
inherently non virtual). JUnit3 uses statics to set up test suites.
2. or we'd use an interface Diagnostics that things could implement
Intuitively this feels like a cleaner approach to me. Admittedly you need
an instance to work with, but we'd just need to document the fact that if
the constructor fails you can't get any diags; it shouldn't be too hard
for tasks implementing this interface to put volatile init code somewhere
other than the constructor.
Well that's it, you see, the diags could be more helpful
3. the -diagnostics command and <diagnostics> tasks could be made to
diagnose a single task
ant -diagnostics -task junit
and maybe even a single antlib namespace
ant -diagnostics -xmlns antlib:org.example.something
Okay, so I see that you've considered the antlib case to a certain extent.
This has me thinking about antlib auto-discovery again. Instead of
requiring users to specify the task or antlib they want diags on, I think
it would be easier for users to add a "-fullDiagnostics" option that would
dump the normal "-diagnostics" info _plus_ whatever task/antlib diags it
could find. For that to work we would need some sort of auto-discovery
mechanism (which has been discussed before).
1. yes, you could do diags on a specific library. We could do it for all
XML namespaces in scope in the doc, since that implicitly triggers some
antlib loading.
2. we could extend every <antlib> declaration with a homepage attribute,
and a diagnostics attr that takes a classname. These would be for
specific things,.
I also think we could add something similar for version information; a
"-fullVersion" flag could dump the normal "-version" info _plus_ version
info about discovered antlibs.
Yes, I'd like to know about known antlibs. Incidentally, Ant1.7.1 lists
all known tasks in a namespace if it doesnt find the one you asked for.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
