ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Roles (was: antlib)
Date Thu, 08 May 2003 02:46:54 GMT
Conor MacNeill wrote:

> On Thu, 8 May 2003 12:30 am, Costin Manolache wrote:
>>
>> The URI however should be chosen by the antlib author ( maybe based on
>> some rules specific to ant ), and should serve as an ID of the library.
>>
>> My proposal is to use the (main) package name. There are other options -
>> but I don't think every end user using it's own name for an antlib is a
>> good one.
>>
> 
> +1
> 
> I believe the URI should be defined by the antlib builder, not the user.
> It should be opaque - no semantic structure, at least from Ant's
> processing. An antlib should just declare to what namespace URI it belongs
> and then that antlib's defs would be accessible through that namespace in
> the build file.

Can you explain why you don't want a semantic structure ?

I don't understand why using a java package name - i.e. the base package of
the library - as ns is worse than using an arbitrary string.  

And I don't unserstand why not using the URI in a meaningfull way - to
locate the descriptor. 

If we use an arbitrary string - we'll still have to use a declaration to
associate it with a resource. 

Of course - using the URI as a file is bad, using it as a HTTP is not very
good either. But a java package name has all the characteristics that a
namespace name needs, and it's intuitive for java developers.


> This would allow multiple antlibs to belong to a single namespace, which
> might be useful for extension purposes. So, something like this

What would be the benefit ? 

IMO it would be more confusing. Even if we don't care about tools - having 
a namespace associated with a clear set of elements and tags is good for 
clarity. 


> <antlib uri="blah">
>   <taskdef>
>   <typdef>
> </antlib>
> 
> Antlibs could potentially declare themselves to belong to the default
> namespace. This would handle Ant's existing optional tasks. This facility
> might be restricted to antlibs found in a particular location.

+1 - the default namespace is a special case. My problem is with
spaghetti-namespaces ( that change names or can be combined ). 

<project xmlsns:antcontrib="ant:net.sf.antcontrib" >
  <antcontrib:if ... >

would become:
 <project> 
  <antlib uri="ant:net.sf.antcontrib"> 
  <if>



In the first case - <if>'s namespace can be used to locate/load the lib.
In the second - an explicit load into the default namespace.


> A classloader could probably be associated with the URI, picking up all
> antlibs declaring the URI.

For advanced uses - ok.

For common use - I think using the main class loader and adding the antlibs
( and their dependencies ) to the main loader is far better.

By advanced use I mean the case where you want to use multiple versions 
of an antlib at the same time, or antlibs that have conflicting deps,
etc.

Costin

> 
> Just some thoughts
> Conor



Mime
View raw message