ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: Name collisions
Date Mon, 04 Mar 2002 06:46:21 GMT

> -----Original Message-----
> From: Jose Alberto Fernandez []
> Sent: Monday, 4 March 2002 1:00 PM
> To: Ant Developers List
> Subject: Re: Name collisions

> > 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
with another role?

> 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,
and 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:

* Use fully qualified type names, e.g. antlib.role.type:

  <import lib="lib1"/>
  <import lib="lib2"/>
  <lib1.task.copy .. >
  <lib2.task.copy .. >

* Similar to Java, an explicit type import has precedence over an implicit import, and it
is an error to explicitly import 2 types with the same shorthand.  This option wouldn't work
on it's own - it would need some way to use the implicitly imported types too.  It's just
a convenience.

  <import lib="lib1">
    <task name="copy"/>
  <import lib="lib2" />
  <copy .. >
  <lib2.task.copy .. >

* Have the ability to alias a type when imported.

  <import lib="lib1">
    <task name="copy" alias="copy1"/>


* Use attributes to provide the missing pieces of information, so that we end up with antlib,
role and type-name.  In some contexts, the role may not be needed.

  <copy ant:lib="lib1" ant:role="task"/>

Another option would be to drop the role from the unique identifier.  This fits better with
how javadoes things.  A type's role doesn't have anything to do with its packaging (the analogy
with java is antlib == package, role == interface).  Just like Java, packaging is where we
want to do the disambiguation 


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

View raw message