Yes, I nabbed an alternative logger from a similar project :-) Basically, it outputs when a target starts and when it finishes, and for each task it outputs [target/task] instead of just [task] so you can see what's going on.
I can't claim any responsibility for it though! On 25 June 2010 11:48, <jan.mate...@rzf.fin-nrw.de> wrote: > btw - when using parallel executors the problem of parallel logging output > must be resolved ;-) > > Jan > > >-----Ursprüngliche Nachricht----- > >Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de] > >Gesendet: Freitag, 25. Juni 2010 12:46 > >An: dev@ant.apache.org > >Betreff: AW: [Proposal] Capture attributes in unknown namespaces > > > >Other point: we have an implementation in the sandbox > >https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor > > > >Maybe you could use some code ;-) > > > > > >Jan > > > >>-----Ursprüngliche Nachricht----- > >>Von: Dominique Devienne [mailto:ddevie...@gmail.com] > >>Gesendet: Donnerstag, 24. Juni 2010 23:12 > >>An: Ant Developers List > >>Betreff: Re: [Proposal] Capture attributes in unknown namespaces > >> > >>On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates > >><da...@codeaholics.org> wrote: > >>> What would be kind of cool would be that if the parser > >>encounters attributes > >>> in a namespace that it doesn't recognise, then instead of > >>ignoring them (as > >>> it does now), it records them and makes them available > >>through an API on the > >>> Project and Target objects. This would allow the executor to > >>inspect them. > >> > >>Something related to that was discussed in the past to allow arbitrary > >>"cross-cutting" attributes to be added to tasks which wouldn't > >>normally support them, typically in the context of adding global > >>ant:if and ant:unless attributes (or maybe I just thought about it, > >>I'm no longer sure ;) > >> > >>> I realise this is very specific to my parallel executor > >>project, but I think > >>> adding it would be a non-breaking change that wouldn't have > >>any impact on > >>> existing consumers of the API. > >> > >>True. But I'd be more in favor of an opt-in framework, where you > >>explicitly tell Ant to record attributes from specific namespaces. > >>From the list, I think other people also use "extra" markup in their > >>builds for "external" tools, so in their case they don't need to > >>record those attributes for examples. > >> > >>> What do you folks think? > >> > >>I think it's a good idea. There are design considerations like, should > >>it be free form string=string recorded as-is, or should these > >>attributes be processed like ordinary attributes Ant deals with to do > >>property expansion and conversion to Java types (like boolean > >>accepting "true"/"on"/"yes" as a true). For example, imagine you group > >>your extra attributes into a DataType part of an AntLib bound to that > >>extra namespace, the DataType could be instantiated "as usual" by Ant > >>provided it looked at the UnknownElement specifically for a given > >>namespace, and then the DataType is "bound" somehow to the task or > >>type or target. That way everything is typed as usual, and could be > >>made to reuse a lot of the existing code/facilities. See what I mean? > >>--DD > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >>For additional commands, e-mail: dev-h...@ant.apache.org > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >For additional commands, e-mail: dev-h...@ant.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
