ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Antlib... when?
Date Sun, 05 Jan 2003 15:43:10 GMT
Conor MacNeill wrote:

>> 3. If you don't need namespaces, you'll not have to use them. I.e. if you
>> have a simple project and use few libs - you can still use the simpler
>> syntax.
> what is the "simpler syntax"? You mean no namespace qualifiers? How do you
> see both these mechanisms working at once? - defining all tasks in the
> default namespace and ignoring collisions?

The current syntax, with no namespaces. Just define the tasks with 
  <taskdef resource="my/antlib/package/ />
or some new
  <antlib name="my.antlib.package" />

The behavior will be to load the tasks just like today, and eventually
generate errors on name conflicts ( with a message that if you have 
conflicts you must use namespaces - you are no longer in the "simple"
case ).

> This means the build file depends on the user's config to some extent. One
> user has no colision and uses <deploy> whilst another does and get the
> wrong <deploy> defined first. Not sure this is good.

Yes, if the user has a simple config with non-conflicting antlibs - he'll
have a simpler build file. He'll still declare what antlibs it uses, and 
if we detect a conflict we can inform him that the simple times have ended
and he must use namespaces ( at least for the antlibs with conflicts ).

>> The xmlns syntax is well defined - the only issue is the semantics of the
>> URI. Some people have strong opinions on that. My (strong:-) preference
>> is for a URI that does have some semantics - i.e. it can be resolved to
>> a java package. Some form of catalog can resolve this to URLs or
>> something else.
> We need to have some mechanism to match the URI to a jar, whatever the URI
> format is. At this stage my pref would be to use a standard HTTP URL from
> which the library may be downloaded (not necessarily directly).

That's a good option too. 

What about combining the 2 variants. My proposal was to use the URI to 
identify the package, and use this to load the descriptor ( assuming
the jar is available and a catalog can help the download ).

We can use the URL, and require that each jar includes a 
META-INF/ant/ENCODED_URL resource for the descriptor. This way you 
have a simple way to match the URL against a .properties ( or .xml )
descriptor, without extra config ( catalog, etc ) or net access.


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

View raw message