Logging and Ant tasks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging and Ant tasks

hans_d
Administrator
Hi,

some Ant tasks don't use the Ant logging system for some of there  
messages but use System.out.println instead. For example the javac  
tasks does this with warnings from the compiler. The launch4j tasks  
does this as well. There is not much we can do about this as long as  
we use those tasks. Sooner or later I think we should have native  
implementations of our core tasks. Not just because of logging. It  
would also increase our flexibility.

Another problem is the Ant Junit tasks. It does not offer something  
like a test summary. Therefore in our high level log the user can't  
find out which tests have failed. They have to look into the test  
reports. But also with INFO logging it is very inconvenient to find  
the test which has failed. When implementing testng integration I  
would like to refactor our test task not to rely on Ant Junit any  
longer but have there own test runners instead. What I also dislike  
about the JUnit Ant task is that it tries to execute Abstract test  
cases. You have to explicitly exclude them.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging and Ant tasks

Adam Murdoch-2


Hans Dockter wrote:
> Hi,
>
> some Ant tasks don't use the Ant logging system for some of there
> messages but use System.out.println instead. For example the javac
> tasks does this with warnings from the compiler. The launch4j tasks
> does this as well. There is not much we can do about this as long as
> we use those tasks.

We would still have this problem if builds do their own writing to
stdout, or if they fork processes, or if they use these ant tasks (or
ones like them) directly.

To solve the problem, we could bridge stdout and stderr across to
logging, with default info level for stdout and error level for stderr.

> Sooner or later I think we should have native implementations of our
> core tasks. Not just because of logging. It would also increase our
> flexibility.
>
> Another problem is the Ant Junit tasks. It does not offer something
> like a test summary. Therefore in our high level log the user can't
> find out which tests have failed. They have to look into the test
> reports. But also with INFO logging it is very inconvenient to find
> the test which has failed. When implementing testng integration I
> would like to refactor our test task not to rely on Ant Junit any
> longer but have there own test runners instead.

I agree. Junit 4 is very easy to invoke directly, and I'm pretty sure
test-ng is as well.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging and Ant tasks

hans_d
Administrator

On Sep 24, 2008, at 10:53 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Hi,
>>
>> some Ant tasks don't use the Ant logging system for some of there  
>> messages but use System.out.println instead. For example the javac  
>> tasks does this with warnings from the compiler. The launch4j  
>> tasks does this as well. There is not much we can do about this as  
>> long as we use those tasks.
>
> We would still have this problem if builds do their own writing to  
> stdout, or if they fork processes, or if they use these ant tasks  
> (or ones like them) directly.
>
> To solve the problem, we could bridge stdout and stderr across to  
> logging, with default info level for stdout and error level for  
> stderr.

Good point. I gonna implement a STDOUT/ERR logging adapter.

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging and Ant tasks

hans_d
Administrator

On Sep 24, 2008, at 11:14 AM, Hans Dockter wrote:

>
> On Sep 24, 2008, at 10:53 AM, Adam Murdoch wrote:
>
>>
>>
>> Hans Dockter wrote:
>>> Hi,
>>>
>>> some Ant tasks don't use the Ant logging system for some of there  
>>> messages but use System.out.println instead. For example the  
>>> javac tasks does this with warnings from the compiler. The  
>>> launch4j tasks does this as well. There is not much we can do  
>>> about this as long as we use those tasks.
>>
>> We would still have this problem if builds do their own writing to  
>> stdout, or if they fork processes, or if they use these ant tasks  
>> (or ones like them) directly.
>>
>> To solve the problem, we could bridge stdout and stderr across to  
>> logging, with default info level for stdout and error level for  
>> stderr.
>
> Good point. I gonna implement a STDOUT/ERR logging adapter.

After having implemented it (not submitted yet) I'm not sure if this  
is really a good idea. After all we 'steal' the normal debugging  
usage of println from the developer. You have to run Gradle with -d  
to see println output (which is delegated to INFO level). The  
alternative would be to delegate println not to INFO but to  
LIFECYCLE. We would not have reduced any noise then but at least the  
messages would end up in a file when doing file logging.

Or we could prepare only our AntBuilder to delegate its System.out/
err output to the logger.

Or we leave things as they are.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email