per-task diagnostics

[Steve Loughran <st...@apache.org>]

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.

With this the -diagnostics routine could run through all tasks that it 
knows about, creates them, and for everyone one that can be created, 
asks for its diagnostics.

This would move logic into the tasks, let junit be aware about its 
needs, xslt and junit report probe for an XSL engine, etc.

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.

2. or we'd use an interface Diagnostics that things could implement

3. the -diagnostics command and <diagnostics> tasks could be made to 
diagnose a single task

  ant -diagonistics -task junit

and maybe even a single antlib namespace

  ant -diagnostics -xmlns antlib:org.example.something

the <diagnostics> task would make it easy to test this stuff on a 
task-by-task basis, and for third party tasks to join in.

Thoughts?



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: per-task diagnostics

[Stefan Bodewig <bo...@apache.org>]

On Wed, 07 Feb 2007, Steve Loughran <st...@apache.org> wrote:

> 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.

I think it should get a Project instance instead of a PrinStream so
that output goes to the logger attached, whatever that may be.

Of course the PrinStream could be wrapping a LogOutputStream, but that
would be taking away the opportunity to log at different levels.

> 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.

Makes sense.

> 2. or we'd use an interface Diagnostics that things could implement

In many cases where required libraries are not there, we will fail to
create a task instance.  In some cases we may even be unable to create
the class, but the "can't create an instance" cases are probably more
common.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: per-task diagnostics

[Steve Loughran <st...@apache.org>]

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: per-task diagnostics

[Jeffrey E Care <ca...@us.ibm.com>]

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 :)

> 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.

> 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).

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.
____________________________________________________________________________________________ 

Jeffrey E. (Jeff) Care 
carej@us.ibm.com 
IBM WebSphere Application Server 
Systems Management Development 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org