ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: [Proposal] Capture attributes in unknown namespaces
Date Fri, 25 Jun 2010 10:48:27 GMT
btw - when using parallel executors the problem of parallel logging output must be resolved


>-----Urspr√ľngliche Nachricht-----
>Von: [] 
>Gesendet: Freitag, 25. Juni 2010 12:46
>Betreff: AW: [Proposal] Capture attributes in unknown namespaces
>Other point: we have an implementation in the sandbox
>Maybe you could use some code ;-)
>>-----Urspr√ľngliche Nachricht-----
>>Von: Dominique Devienne [] 
>>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 
>><> 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?
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message