You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2001/07/27 08:23:39 UTC

TaskContainer and logging

DefaulLogger is safe, as far as I can tell, it just uses information
from the current BuildEvent directly, but XmlLogger is a completely
different issue.

In order to know which parent element a given task element should be
attached to, the logger would have to ask either the Task itself or
the BuildEvent - in the case of <parallel> neither the Thread instance
nor the Task last started and not closed will work.

There is no chance the BuildEvent could know the parent, unless the
task itself would know its parent, I hope I'm just too blind to see
it, as I wouldn't want to add get/setParent to Task just to enable
logging (even though get/setOwningTarget is probably there for much
the same reason only).

Does anybody see a viable alternative?

Stefan

RE: TaskContainer and logging

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Thomas Christen [mailto:chr@active.ch]
>
> > It has been so long, you forgot about generating patches :-)
>
> Oops - shall I still do this ? (was out for a few weeks - sorry)

No need. I looked at your code but it required changes to the project and
task objects that I was not keen to implement. I used the idea of the timed
element and then managed it all in the XMLLogger implementation. I'd be
happy to have your feedback on the code I committed, if you have the time.

Conor


AW: TaskContainer and logging

Posted by Thomas Christen <ch...@active.ch>.
> It has been so long, you forgot about generating patches :-)

Oops - shall I still do this ? (was out for a few weeks - sorry)

Can I be of help for the other task I've sent earlier ?

Regards
Thomas

Re: TaskContainer and logging

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Thomas,

It has been so long, you forgot about generating patches :-)

Conor

----- Original Message -----
From: "Thomas Christen" <ch...@active.ch>
To: <an...@jakarta.apache.org>
Sent: Monday, July 30, 2001 8:07 PM
Subject: AW: TaskContainer and logging


>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> > Gesendet am: Montag, 30. Juli 2001 01:40
> > An: ant-dev@jakarta.apache.org
> > Betreff: RE: TaskContainer and logging
> >
> > Sure. Send it in.
> >
>


AW: TaskContainer and logging

Posted by Thomas Christen <ch...@active.ch>.

> -----Ursprüngliche Nachricht-----
> Von: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> Gesendet am: Montag, 30. Juli 2001 01:40
> An: ant-dev@jakarta.apache.org
> Betreff: RE: TaskContainer and logging
>
> Sure. Send it in.
>

RE: TaskContainer and logging

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Sure. Send it in.

> -----Original Message-----
> From: Thomas Christen [mailto:chr@active.ch]
> Sent: Monday, 30 July 2001 1:32 AM
> To: ant-dev@jakarta.apache.org
> Subject: AW: TaskContainer and logging
> 
> 
> I wrote a new one (multi thread safe) interested in ? pse tell me.
> Thomas Christen
> 


AW: TaskContainer and logging

Posted by Thomas Christen <ch...@active.ch>.
I wrote a new one (multi thread safe) interested in ? pse tell me.
Thomas Christen

> -----Ursprüngliche Nachricht-----
> Von: Stefan Bodewig [mailto:bodewig@apache.org]
> Gesendet am: Freitag, 27. Juli 2001 09:13
> An: ant-dev@jakarta.apache.org
> Betreff: Re: TaskContainer and logging
>
> On Fri, 27 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
> wrote:
>
> > First question I have is whether we could just flatten the tasks
> > within the Target and report them that way. The task relationships
> > within the target could potentially be ignored for logging. That
> > would mean we don't need to care about the parent relationship.
>
> Yes and no - it is possible to have multiple open targets with ant or
> antcall inside <parallel>, but the logic here could be rewritten.
>
> We would lose structural information with that approach, of course.
> I've got no real opinion here.
>
> > In any case, the taskElement and taskStartTime needs to be changed
> > from a single variable into a Map.
>
> Yes, same for targets.
>
> > We probably need to sort on task start time in the targetFinished
> > method.
>
> Yes.
>
> > Other than that we may need to add the parent reference (A
> > TaskContainer). I can't see any harm, even if it just to support
> > logging. It may make OwningTarget redundant.
>
> This is the major problem - it does make the OwningTarget redundant,
> but we cannot remove it savely (that backwards compatibility stuff).
>
> The harm I see is API bloat combined with more backwards compatibility
> issues in the future.
>
> > So, we are going to have put some sort of warning about that in
> > WHATSNEW file.
>
> Yes - we may need a new section for this, as it is no real backwards
> compatibility problem (you will only notice the problem when you use
> the new features, especially the parallel task).
>
> Stefan
>


Re: TaskContainer and logging

Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 27 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:

> First question I have is whether we could just flatten the tasks
> within the Target and report them that way. The task relationships
> within the target could potentially be ignored for logging. That
> would mean we don't need to care about the parent relationship.

Yes and no - it is possible to have multiple open targets with ant or
antcall inside <parallel>, but the logic here could be rewritten.

We would lose structural information with that approach, of course.
I've got no real opinion here.

> In any case, the taskElement and taskStartTime needs to be changed
> from a single variable into a Map.

Yes, same for targets.

> We probably need to sort on task start time in the targetFinished
> method.

Yes.

> Other than that we may need to add the parent reference (A
> TaskContainer). I can't see any harm, even if it just to support
> logging. It may make OwningTarget redundant.

This is the major problem - it does make the OwningTarget redundant,
but we cannot remove it savely (that backwards compatibility stuff).

The harm I see is API bloat combined with more backwards compatibility
issues in the future.

> So, we are going to have put some sort of warning about that in
> WHATSNEW file.

Yes - we may need a new section for this, as it is no real backwards
compatibility problem (you will only notice the problem when you use
the new features, especially the parallel task).

Stefan

RE: TaskContainer and logging

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> DefaulLogger is safe, as far as I can tell, it just uses information
> from the current BuildEvent directly, but XmlLogger is a completely
> different issue.

Agreed.

>
> In order to know which parent element a given task element should be
> attached to, the logger would have to ask either the Task itself or
> the BuildEvent - in the case of <parallel> neither the Thread instance
> nor the Task last started and not closed will work.
>
> There is no chance the BuildEvent could know the parent, unless the
> task itself would know its parent, I hope I'm just too blind to see
> it, as I wouldn't want to add get/setParent to Task just to enable
> logging (even though get/setOwningTarget is probably there for much
> the same reason only).


First question I have is whether we could just flatten the tasks within the
Target and report them that way. The task relationships within the target
could potentially be ignored for logging. That would mean we don't need to
care about the parent relationship.

In any case, the taskElement  and taskStartTime needs to be changed from a
single variable into a Map. We probably need to sort on task start time in
the targetFinished method.

Other than that we may need to add the parent reference (A TaskContainer). I
can't see any harm, even if it just to support logging. It may make
OwningTarget redundant.

I'll look into it a bit more tonight.

As Peter has said, many loggers retain state assuming a serial task
execution flow. These are going to break in the face of TaskContainers. So,
we are going to have put some sort of warning about that in WHATSNEW file.

Conor