ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: NameSpace & antlib was (Re: polymorphism)
Date Tue, 29 Apr 2003 09:46:04 GMT
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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message