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:17:39 GMT
> From: Costin Manolache [mailto:cmanolache@yahoo.com]
> 
> 
> I think you started with wrong assumptions here.
> 
> There is no need to change anything in the core or optional tasks, 
> you can have an antlib that uses multiple jars ( and most 
> likely antlibs
> will eventually use some dependency mechanism and have 
> mutliple jars ).
> 
> 

So you want to continue with the aberration of allowing having
tasks in the descriptor that cannot be loaded or fail to resolve 
due to lack of dependencies? This is what we have to allow today
in order to have those magic property files that contain all the
optional tasks. At least I was striding to get rid of it.

But if you impose the rule "one antlib one URI" (as it was suggested)
then you have to continue with this aberration just for backward compatibility.

Let me just make clear that I am assuming the content of an "antlib"
is defined by its XML (or whatever) descriptor.

> > 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.
> 
> The namespace is not under user control - by definition. Read 
> the W3C spec,
> it is designed to be fixed, stable, durable, etc. 
> And there is no point in the user changing the namespace URI 
> - the ns is 
> the id or name of the library.
> 

There is definetly nothing on W3C about antlib libraries. The URI
is just a string and W3C imposes no meaning to it. Whether it is 
universally unique or not is just suggested not impossed,
the same as public-ids for DTDs. As long as you can distinguish
between two diferent things that is all that is required.

> Regarding use of the core namespace if no name conflicts: +1
> 

So I am an <antlib> writer and have a <shitch/> task and because
it does not conflict with core I fix it in the core namespace.
So ANT 1.7 comes along and decides to add a <switch/> task to core.
Now what, did 1.7 broke backward compatibility? My antlib is now
incompatible with the new version of ANT eventhough no APIs where
mofified. Is ant.apache.org gonna monitor all 3rd party
<antlibs> to make sure core never uses a name someone else
already used?

This is a administration nightmare. This is why I am saying
let the user resolve the conflicts, if he decides to use two
antlibs with clashes, then allow him to load them is separate
namespaces to resolve its own conflicts.

> 
> 
> > 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">
> 
> Again - the URI is not under user control, but under the antlib author
> control. Just like the "if" and the other task names. 
> Allowing the user to
> rename tasks would be very wrong and confusing. ( let's 
> rename "<delete>"
> to "copy", then import few files - and figure out what the 
> build file is
> actually doing ). 
> 

Tell me where in the introspection engine this is required.
This is just your idea. Antlib could pick the namespace dynamically
at loading time. 

And lets just say that today I could rename all tasks to french
names if I wanted just need to write a properties file.
(granted the inner-elements will continue in english, but hey).

Jose Alberto

Mime
View raw message