Ant log message levels for output of Exec-like tasks

[Jim Doyle <jd...@iso-ne.com>]

Hi,

We've just added our Ant build to CruiseControl and are working to make 
it as usable as possible.  One of our issues is the interpretation of 
Ant log messages by CruiseControl.  CruiseControl captures all log 
messages issued by the Ant build and captures the messages' levels 
(DEBUG, INFO, etc.).  The CruiseControl reporting app uses these levels 
to filter what gets displayed in different sections of the build 
report.  By default, all Ant WARN or ERROR messages are displayed in 
CruiseControl's "Errors/Warnings" report.  Naturally, we're now 
interested in making sure our build's Ant log messages are logged with 
an appropriate level.  I think this is similar to other Ant users' 
concerns - see the "Setting Project.MSG_ERR for compiler error messages" 
message posted just today.

It seems like it's basically the individual task that's responsible for 
figuring out the log level for a given message it issues.  Some tasks 
give the buildfile control over this - like <echo> - while others don't 
- like <java>.

I'd like to propose that exec-like tasks like <exec> and <java>, which 
already support <redirector> functionality for process output, extend 
that functionality to allow <redirector>s that say exactly how Ant 
should log the output from the exec'd process.  In Ant 1.6.5 you can 
specify a <redirector> that redirects stdout and stderr, independently, 
to a property or to a file:

<exec executable="cat">
  <redirector outputproperty="redirector.out"
                     error="outputs/redirector.err.txt"/>
   </redirector>
</exec>

What if you could specify a <redirector> that redirects to Ant log 
messages, but explicitly sets the log level:

<exec executable="cat">
  <redirector outputproperty="redirector.out"
                     errorlog="true"
                     errorloglevel="INFO"/>
   </redirector>
</exec>

The above redirector would send cat's stdout to the Ant property 
"redirector.out", while sending cat's stderr  to the Ant log as INFO 
messages.  Or what I think would be better syntax:

<exec executable="cat">
  <redirector>
    <output>
       <property name="redirector.out"/>
     </output>
     <error>
        <log level="INFO"/>
     </error>
   </redirector>
</exec>

I understand that logging a process's stdout as INFO messages and its 
stderr as WARN messages is a good general rule.  But different programs 
use stdout and stderr in different ways.  Some programs really do use 
stderr to separate critical errors that the user must see, so that 
stderr really should be a higher level than stdout.  Other programs use 
stderr to separate verbose information that may only be interesting to 
the user while running the program and shouldn't be considered part of 
the real output, so that stderr may actually be less important than 
stdout.  Therefore it makes more sense to treat stdout and stderr as 
separate categories of messages rather than different levels, where one 
is always more important than the other.

Does anyone else see this as a useful enhancement to Ant's <redirector>?

Thanks,
Jim


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

Re: Ant log message levels for output of Exec-like tasks

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

Jim Doyle wrote:
> Hi,
> 
> We've just added our Ant build to CruiseControl and are working to make 
> it as usable as possible.  One of our issues is the interpretation of 
> Ant log messages by CruiseControl.  CruiseControl captures all log 
> messages issued by the Ant build and captures the messages' levels 
> (DEBUG, INFO, etc.).  The CruiseControl reporting app uses these levels 
> to filter what gets displayed in different sections of the build 
> report.  By default, all Ant WARN or ERROR messages are displayed in 
> CruiseControl's "Errors/Warnings" report.  Naturally, we're now 
> interested in making sure our build's Ant log messages are logged with 
> an appropriate level.  I think this is similar to other Ant users' 
> concerns - see the "Setting Project.MSG_ERR for compiler error messages" 
> message posted just today.

Its an interesting thought. Normally when I  fiddle with logging I use 
the Log4JListener and then you get full control over the log. But CC is 
doing its own capture, which stops you doing that.

> 
> It seems like it's basically the individual task that's responsible for 
> figuring out the log level for a given message it issues.  Some tasks 
> give the buildfile control over this - like <echo> - while others don't 
> - like <java>.
> 
> I'd like to propose that exec-like tasks like <exec> and <java>, which 
> already support <redirector> functionality for process output, extend 
> that functionality to allow <redirector>s that say exactly how Ant 
> should log the output from the exec'd process.  In Ant 1.6.5 you can 
> specify a <redirector> that redirects stdout and stderr, independently, 
> to a property or to a file:
> 
> <exec executable="cat">
>  <redirector outputproperty="redirector.out"
>                     error="outputs/redirector.err.txt"/>
>   </redirector>
> </exec>
> 
> What if you could specify a <redirector> that redirects to Ant log 
> messages, but explicitly sets the log level:
> 
> <exec executable="cat">
>  <redirector outputproperty="redirector.out"
>                     errorlog="true"
>                     errorloglevel="INFO"/>
>   </redirector>
> </exec>
> 
> The above redirector would send cat's stdout to the Ant property 
> "redirector.out", while sending cat's stderr  to the Ant log as INFO 
> messages.  Or what I think would be better syntax:
> 
> <exec executable="cat">
>  <redirector>
>    <output>
>       <property name="redirector.out"/>
>     </output>
>     <error>
>        <log level="INFO"/>
>     </error>
>   </redirector>
> </exec>


yeah, that looks good. Feel free to write it *and* the unit tests, and 
we can add it to Ant1.7. Ant's testharness does capture stdout and 
stderr, so you can make assertions about what gets logged.

-steve

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