ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: Roles (was: antlib)
Date Wed, 07 May 2003 23:40:11 GMT
> From: Wannheden, Knut [mailto:knut.wannheden@paranor.ch]
> 
> > I have no problem on allowing people to use namespaces, but I do 
> > have a problem on forcing people to use them just because 
> some others
> > want to use some fancy XML tool. The buildfile belongs to the
> > user and s/he should be in charge.
> > 
> 
> As someone already said, it's about "not reinventing the 
> wheel", not about
> enabling the use of fancy tools.  But as ubiquitous and 
> accepted as XML
> namespaces are, I see many things that could be gained from using
> namespaces.  Also, I suspect most users familiar with XML 
> will have had some
> dose of contact with namespaces.
> 

But ANT is not for experience XML users but for Java programmers
or C or .NET (with the new tasks). ANT is popular because
it is simple to use you do not have construccions that require
you to read a full spec to understand. I am not against NS, but
I am against forcing people to use them just because.

> > > Also namespaces lets the antlib user specify what prefix to 
> > > use.  But it
> > > doesn't allow two antlibs to use the same prefix in the 
> > > context of the same
> > > element, which I think is good.
> > > 
> > 
> > This sounds proper in theory, but in practice lets see:
> > 
> >  1) Lets assume that we still want to be able to chop ANT jars
> >     between core and different optional jars which have specific
> >     dependencies of diferent packages and such.
> > 
> >  2) Now because they are in different antlibs it would mean I am
> >     forced to use different namespaces for each.
> > 
> 
> Is that really so?  As I understood it antlibs wouldn't be a 
> requirement for
> providing Ant tasks and types.  I thought the normal <taskdef/> and
> <typedef/> would still work as they do now.
> 

So again you have a two tier world where some things are more core
than others. Me as a library provider need to decide now whether
to ship my library with a property file so that it can be incorporated
seemingly into ANT namespace or use an XML definition and force
my users to learn NS. Hummmm

> I suppose it would also be possible to let one antlib extend 
> another one,
> thus letting it use the same namespace.
> 

The suggestion I was critisazing was that of having "one ANTlib one URI"


> >  3) So now you have people using 3rd party tasks like antcontrib
> >     without problem and without conflicts, but they would have to
> >     change not just one line (to use the antlib) but every bloddy
> >     use of the tasks just because they are forced to use 
> name spaces.
> > 
> 
> To use antcontrib as an antlib they would at the very least 
> have to replace
> the <taskdef/>s with an <antlib/> element or something, no?  
> But the tasks
> should still work as they do now using <taskdef/>.
> 

So not the antlib writer will have to provide both an XML descriptor 
AND a properties file? How about all the fancy typing?

> > > If you really want you can use short names with namespaces as 
> > > well.  Just
> > > set the default namespace locally.
> > > 
> > 
> > I have no problem using XML namespaces as long as they are 
> independent
> > of the antlib and under complete user control (not antlib 
> > designer control).
> > In other words the user should be able to decide if s/he 
> wants to load
> > the library on some particular namespace or in the default "" 
> > namespace
> > which is the one used by core.
> > 
> > So if I say:
> > 
> > 	<antlib location="antcontrib.jar"/>
> > 
> > I will be able to use: <if/>, <switch/>, etc. But is I do:
> > 
> > 	<project xmlns:cont="mylibs">
> > 	   <antlib location="antcontrib.jar" usens="cont"/>
> > 
> > 	</project>
> > 
> > then I can use <cont:if/>, <cont:switch/>, etc.
> > 
> 
> I think the <antlib/> shouldn't define the prefix, but the 
> namespace URI
> instead .  Something like:
> 
> 	<project xmlns:cont="urn:uri-supplied-by-ant-user">
> 	   <antlib location="antcontrib.jar"
> ns="urn:uri-supplied-by-ant-user"/>
>          <cont:if/>
> 	</project>
> 

I thing this is what I meant (in escense), with the understanding
that:

	a) the user can use the same URI on several <antlib>s
	   (any conflicts are his problem)

	b) the default value for the ns attribute is ns="".

> Of course if the antlib would provide its own namespace in 
> the descriptor.
> Ant could do some kind of automatic loading when a namespace 
> declaration
> matching the namespace URI is encountered.  But I'm not sure 
> that's a good
> idea.
> 

Agreed it is not good idea.

> > Which means that the default value for the 'usens' attribute 
> > is "" which assumes
> > some implicit namespace definitions like:
> > 
> > 	xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"
> > 
> > which uses as kosher namespaces as possible, I think.
> > 
> 
> But this would require that the <project/> element would 
> define the default
> namespace like this:
> 
> 	<project xmlns="ant-namespace">
> 		...
> 	</project>
> 
> Why not use the empty namespace for Ant core?
> 

Fine with me.

Jose Alberto

Mime
View raw message