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 01:49:49 GMT
Conor MacNeill wrote:

> Costin Manolache wrote:
>> But we have namespace support now ! :-)
> You mean XML namespace support? That is (potentially) different from the
> task/type namespace. Perhaps XML namespace can be used for task
> resolution. It has been mooted in the past for other roles (identification
> of aspects, such as a documentation aspect). We probably need some
> agreement on how/if to use XML namespaces in Ant.

My 'itch' is to have pluggable support for component creation. If nobody
-1 the ComponentHelper - then any antlib can be implemented as an 
optional task. I'll probably be ok with any "official" solution ( if
it isn't too complex ), and probably I'll do my own experiments.

Having a simple ComponentHelper plugin that uses the XML namespace to
load a simple properties descriptor is one reasonable solution. Certainly
not the only one. 

>> And naming collision was allwasy a possiblity with taskdef.
> Indeed. Every time we change we can cause people to
> have to rewrite their build files to avoid the collision. It may even
> break existing build files, I'm not sure. This problem is much smaller
> than the problem that will exist when we provide an Antlib concept. IOW, I
> don't think we can argue that the pre-existence of a problem allows us to
> neglect that problem in the future.

My point was that naming conflicts are not the biggest problem we are 

The only way I know to avoid naming conflicts is to use a namespace. Not 
using the XML namespace if we do need a namespace ( and inventing our own ) 
would be a very bad idea IMO. 

I don't think that the antlib concept will directly increase the number
of tasks or the likelyhood of conflicts. 

Renaming tasks is a very different issue. Renaming existing tasks is yet
another issue ( and see no reason for it to happen - I think we agree on

> When we have antlibs, I expect people and companies to start shipping
> antlibs. Let's say, for example, that tomcat and an app server provider
> both
>   ship antlibs and both provide a <deploy> task. How can I use those
>   tasks?
> If you believe this can be supported through XML namespaces, we need to
> work out what the build file looks like for that, I think.

How is that different from tomcat shiping a properties file ( and using
taskdef resource=... ) ? People and companies are already shipping 
ant tasks and libs.

If we want to use XML namespaces to reduce the chance of conflicts - and
this can be optional, so "simple" build files will not have to do it - 
then the syntax is pretty clear. 

  <project xmlsns:tomcat="...." >
   <tomcat:deploy ... >
I don't see too many choices for that ( the URL of the NS is the only 
big issue ).

Do you see any other option on resolving name conflicts in 
xml files ? 

> Let's talk about what the build file looks like and work from there.

I think we should agree on some basic issues:

1. If a namespace will be used to resolve conflicts - it will be XML 
namespace ( i.e. we won't invent our own ).

2. Existing files will not have to change. ( i.e. the default namespace
will be used for the core tasks ).

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

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


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

View raw message