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
