ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Roles (was: antlib)
Date Wed, 07 May 2003 15:17:39 GMT
Jose Alberto Fernandez wrote:

>> From: Wannheden, Knut []
>> > 
>> > Let's not reinvent the wheel here.
>> > 
>> > The solution for names conflicts is namespaces - not rewriting.
>> > 
>> I agree.  With the new ProjectHelper2 everything should be in
>> place to start
>> using namespaces.
> 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.

Namespaces are the common solution used to resolve name conflicts.

I have a big problem on using some "original" solution like renaming 
tasks with some prefix. 

This has nothing to do with "fancy XML tools" ( in fact, very few 
editors are able to deal nicely with namespaces ). We have a problem - name
conflits - and one solution. 

I like Perl and the "there is more than one way to do things", but in
this case we have a standard solution that everyone uses, and it would be
very confusing and wrong to force the user to learn a different one.

>> This would also allow antlibs to have a DTD or XML Schema
>> which could be
>> used in XML editors or for validation.
> Well ANT's XML is the result of introspection, and we already know
> our object model cannot be represented by a simple DTD. I see no way
> or reson to enforce 3rd party libraries to define their objects
> to be DTD-able.
> I am not sure about XMLSchema but my hopes are not too high.

I agree with you on this one. XMLSchema is one of the worse things
I've seen. 

However it is possible to associate a DTD/schema with (most) of the
ant ( we even have a dtd generator, that works great with emacs, I use 
the DTD every day ). And some users may choose to create build files
with editors using only the subset of ant that is supported by the editor
( i.e. fits the restrictions of the DTD/schema ).

>> 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.

Why ? I think most people agreed that using the jar file name as a 
namespace URI is not the best solution.

If we go with the package name ( or other solution where the ns is fixed 
by the antlib creator ) - you can have the files in multiple jars.
For package name - the descriptor will have to be in that package.

>  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.

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 ).

> I doubt many people will be fill happy about that, and the backward
> compatibility consequences.
>> 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.

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.

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

> 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 ). 

> <antlib location="antcontrib.jar" usens="cont"/>
> </project>
> then I can use <cont:if/>, <cont:switch/>, etc.


> 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.
> Jose Alberto

View raw message