Two points
1)
Using /org/apache/.../anlib.xml defeats the purpose of the antlib
proposal.
However it is in keeping with current ant practice.
it could be supported using
<typedef definitionresource="/org/apache/commons/modeler/ant/antlib.xml">
<classpath path="${commons.modler"/>
</typedef>
or using nested elements
<typedef loaderRef="commons.classloader">
<definition resource="/org/apache/commons/modeler/ant/antlib.xml">
<definition resource="/org/apache/commons/jelly/antlib.xml"/>
</typedef>
antlibs would still have the fixed location for the ant descriptor
<typedef antlib="${ant-contrib.jar}"/>
2)
Using xml namespaces is opening a big can of worms. I do
not think that it is a good idea to just introduce them for antlibs.
And I certainly do not think that agreement on their use will be reached
in a 1.6 timeframe. Also the implementation is a bit problemantic
(multiple symbols tables in use depending on the xml parsing of
the build file)
The reason for using them is just to remove name clashes from
loading various third party ant extensions. I think that adding
a prefix attribute to typedef solves this particular problem.
<typedef antlib="${ant-contrib.jar}" prefix="antcontrib."/>
<typedef antlib="${antelope.jar}" prefix="antelope."/>
<antelope.swatchwatch name="timer1"/>
<antcontrib.if ... />
<antelope.swatchwatch name="timer1" action="total"/>
<antelope.swatchwatch name="timer2"/>
<antelope.if ... />
<antelope.swatchwatch name="timer2" action="total"/>
Peter
On Tuesday 29 April 2003 04:24, Costin Manolache wrote:
> J.Pietschmann wrote:
> > Costin Manolache wrote:
> >> There are working and valid systems ( Axis, Xslt ) that use the
> >> namespace with associated meaning.
> >
> > The expanded XML element/attribute names get a meaning through an
> > processing model, nobody denies this. The problems start if someone
> > associates a specific semantic with the form of a namespace name,
> > for example mandating that it points to a library in order to
> > associate expanded element names with a meaning rather than to
> > use a single spec.
>
> I agree that having the NS URI as a file path on the local system
> wouldn't be perfect. And IMO it would be also bad to use some completely
> meaningless and random UUID.
>
> Something in the middle - like the package name - would be IMO good
> enough.
>
> For example:
> xmsns:jmxantlib="ant:org.apache.commons.modeler.ant"
>
> The package can be used to locate an /org/apache.../antlib.xml.
>
> Keeping antlib.xml in the package would avoid merging problems ( in
> META-INF - if you combine 2 jars for example ), and may be even cleaner.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
