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
