ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: ResourceCollections
Date Thu, 07 Apr 2005 14:36:47 GMT
> From: Peter Reilly []
> I do not like "ant:mappers", etc

I don't have much of a problem with it myself now.
It's been argued, winning me over, that the ant: prefix
is already reserved, and thus it's an acceptable solution
solution to this problem, and Matt idea of loading role.xml
for ant:<role> is elegant enough, no?

> This does not use the method "antlib:<package name>" that antlibs
> are meant to be identified by. If "ant:<whatever core wants>" is
> used to identify ant's antlibs', then there is ample reason for
> thirdparty antlibs authors to ask for "easy to use" XML uri
> identifications for their antlibs.

As I wrote earlier I also like the antlib:<package> convention.
That's what I proposed we used in the first place. But others
think it's too verbose. Surely you can see where they're coming
from Peter ;-)

> For core ant types, I do not think it is a good idea - the namespace
> syntax will "get in the way".

Not really. Within Ant itself, you would never need to specify
NS for mappers, selectors, etc... Because Ant types using them,
instead of having one elegant add(FileSelector) method, they have
tons of add<this>(FileSelector).

The need for namespaced types arises for 3rd party which do use
the more elegant and extensible add(Type) methods!

Use a namespace is tons more elegant than having to explicitly
typedef each one you want to use like I had to do. If you refuse
to add role-specific antlibs, then I'll have to define them
myself in my custom AntLib, which clearly breaks encapsulation.

> For about a year now, new mappers, conditions, selectors and filters
> have been added by making them typedefs.

If so, why did I need to typedef the date and size selectors
when I'm using Ant 1.6.2?

> We should be able to make all the current conditions, selectors and
> filters be typedefs.

But then you're polluting the global namespace IMHO.

Types where originally for elements that could stand on their
own at the top level, or directly inside targets. All these
new types you are defining in the global namespace OTOH are
meant to be used only in a very narrow context, within another
(real) type or task.

> There are only a few name over-laps:
>    and, or, not  (selectors and conditions)
> Of course this will change with the selectors for the
> new resource collections,  - but it may be possible to
> be clever.

Precisely. We already have name conflicts, and it will
only get worse. Namespaces are meant to resolve name
conflicts. Lets try to not get too clever trying to
implement another mechanism for this.

> It is quite easy to write a type that is a container for
> selectors and conditions (attached) that will act as a
> container for selectors or for conditions.

It's my turn to not like this. As you say, it's clever,
but now you're writing code to disambiguate name clashes,
and the more name clashes appear, the more you write code...

So to summarize, you Peter don't need to use any namespace
when using Ant roles, because you're likely to use then in
the context of Ant types/tasks, which have specialized add
or create method for them.

I, otoh, but using the new flexible add(Type) method, have
forced to use namespaced Ant roles (mapper, selector), and
that's perfectly alright with me.

It is my opinion that Ant roles should *NOT* be added as
types (if some were, then for BC reason they can stay that
way, but only if they appeared in an official release), to
avoid polluting the global namespace.

As a consequence, like I said in the first place, we need to
define Role-specific AntLibs (and thus namespaces). And I
personally don't care if we use ant:<role> or antlib:<package>.
What I wanted in the first place, and still want obviously,
is for these to be defined, so I don't have to explicitly
typedef myself pre-defined Ant role impls in my build script.

If somehow we go your proposed put-them-all-as-types route,
then I also won't have to typedef them explicitly, which I
like, but we haven't resolved the name conflicts at all.
And your proposed clever solution to this is not an acceptable
solution to me (at this point).

The ideal solution would be in fact to allow registering
several classes/types under the same name, and the Ant runtime
to pick the one type for which isA(Type) is true, fort the Type
at hand, failing with an Ambiguous error if more that one such
type exists. This way, you could register AndSelector and
AndCondition with <and>, and use the 1st in the context of
add(FileSelector), and the 2nd when with an add(Condition).
This doesn't eliminate all conflicts, as for example your
ContainerConditionOrSelect has both, it would be Ambiguous

To me, using role-specific AntLibs is simply the only foul
proof solution to name conflicts, that fits the existing
behavior of Ant. --DD

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

View raw message