ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Name collisions
Date Mon, 04 Mar 2002 08:29:47 GMT
From: "Adam Murdoch" <>
> > From: Jose Alberto Fernandez []
> > 
> > > In ant2 it is likely that we will have types in different roles 
> > with the same 
> > > shorthand name. For instance myrmidon has a "classic" ProjectBuilder, a 
> > > "classic" Configurerr and a "classic" ProjectListener (all 
> > emulating ant1.x 
> > > behaviour). 
> > > 
> > 
> > Oh, you can do the same thing in <antlib>. That is not a problem. 
> > The problem is that
> > one also may have different roles whose namespaces have been 
> > amalgamated. 
> Just out of interest, what does that mean exactly?  What is a role that shares a namespace
> another role?

It means that you want all those roles to be available in the same places and even in containers
that were defined before your new role existed. The case of task/data-type is
a good example. Another was the whole discussion about "beans without execute()".
In the <antlib> proposal you just define a new role "superbean" using the TaskContainer
and providing the new SuperBeanAdapter and presto! you can use these beans any place
a task can be used. 

Simple and powerful.

> > This
> > happens when 2 roles use the same definition for the container 
> > interface (with different 
> > adapter, for example). This is the mechanism used in <antlib> to 
> > model the behaviour
> > of task and data-type. Data-types can be used anywhere a task can 
> > be used  which means that they use the same container interface.
> > 
> > The issue is what to do in this amalgamated name space situation.
> > 
> For Ant 2, I guess there's a few things we can do.  One option would be to use the {antlib,
role, > type-name} combo, to uniquely identify each type.  It's an easy constraint to enforce,
> something that the task writer has complete control over.
> The type-name should be usable on its own, unless it is ambiguous.  In the cases where
it is 
> ambiguous, the build file writer needs to be able to tell us explicitly which one they
mean to use.  > Some options:

So what happens if I just do:
    <typedef name="A" ... />
    <taskdef name="A" ... />

not from a library but from an on the fly definition (like when one compiles and uses the
task on the same build.

> * Have the ability to alias a type when imported.
>   <import lib="lib1">
>     <task name="copy" alias="copy1"/>
>   </import>
>   <copy>
>   <copy1>

You can do this in <antlib> but the point is what does the system should do if you do
do that.

Jose Alberto

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

View raw message