ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject Re: [Proposal] Capture attributes in unknown namespaces
Date Thu, 24 Jun 2010 21:12:00 GMT
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:

View raw message