ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: Task help
Date Thu, 19 Oct 2006 10:41:02 GMT
On 10/19/06, <> wrote:
> >> >I am thinking of adding:
> >> >
> >> >  <project xmlns:ac="antlib:net.sf.antcontrib">
> >> >     <typedef antlib="antlib:net.sf.antcontrib"
> >> >                   classpath="${PATH_TO_ANTCONTRIB.JAR}"/>
> >> >
> >> >which would be equilivent to
> >> >  <typedef uri="antlib:net.sf.antcontrib"
> >> >                resource="net/sf/antcontrib/antlib.xml"
> >> >                classpath="${PATH_TO_ANTCONTRIB.JAR}"/>
> >>
> >>
> >> Would it be easier to have
> >>
> >> <typedef
> >>     antlib="net.sf.antcontrib"      no need for antlib: protocoll as
> its the only
> >>     xmlns="ac"                      no need for name-equality between
> <project xmlns> and <typedef>
> >>     resource+uri                    together with xmlns: if you dont
> use antlib+xmlns attribute
> >>     classpath                       as before (also support of nested
> <resources>?)
> >> />
> >
> >I would rather use the same value as the xmlns binding
> >attribute,  i.e. the XML namespace that the antlib is placed in.
> Ok with me
> >The idea of antlibs is to use standard XML namespaces to
> >handle namespace issues of having multiple antlibs.
> Nothing against that. But the problem is to specify where to load the
> classes from.
> Thats why you have to have a <typedef classpath/> if the jar isnt on
> Ants locations.
I am not sure where you see the problem, perhaps my original e-mail
was misleading, the proprosed antlib attribute would just be a short-cut
for uri="antlib:<package>" resource="<resouce path to package.antlib.xml">
all the other elements / attributes of <typedef> are not changed.

(Note: my choice of "uri" as an attribute name for XML namespace was incorrect
- it should have been "namespace" - that would be clearer - for example it is
the attribute used by XMPP extensions).

> Im not a friend of writing long strings equal to multiple places ....
> What about
>     <project xmlns:ac="...">
>         <typedef xmlns="ac" ...>       xmlns instead of your antlib
> attribute.
This does not work nicely for a number of reasons...

Ok, the reasons are:
1) the typedef may be done before the binding of prefix to namespace

<condition property="for.avail">
   <typefound uri="antlib:net.sf.antcontrib" name="for"/>

<target name="define.for" unless="for.avail">
    <typedef antlib="antlib:net.sf.antcontrib">
        <classpath .../>

<target name="loop" xmlns:ac="antlib:net.sf.antcontrib" depends="define.for">
    <ac:for param="i" begin="1" end="10">
            <echo>count is @{i}</echo>

2: in xml land the namespace uri is the definitive namespace, the prefix is
    just a short cut.

  (However I have seen examples where prefixes are used in attribute values).

3: ant tasks do not have access to the xml namespace prefix.

4: (minor) xmlns cannot be used as an attribute name  - all attribute names
    that start with "xml" are reserved for use by the XML engine.

There is something about xml namespaces that makes it
difficult to understand/use correctly, I cannot put my finger on it.

It may be due to the relationship between prefixes and uris.
1) uris are the definitive namespace
2) however one cannot use them directly, one must map a name (called
   a prefix) to them.
3) the scope of the mapping is enclosed in the element defining the
    mapping, the mapping is done by xmlns[:prefix]=uri

personaly I think that the prefix mapping should have been done in
an xml PI (with the scope for the document) and not in the element, but
I am sure that there had been reasons that this was not done. (default
namespace being one of them).



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

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

View raw message