By the way, if you're interested in taking a look at my work, you can find it here:
http://parallel-ant.googlecode.com/svn/trunk/ On 25 June 2010 11:59, Danny Yates <da...@codeaholics.org> wrote: > 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 >> >> >
