On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >    - should the default uri be "antlib:org.apache.tools.ant" to
> >      be consistent with other antlib uri's
>
> it would only be consistent if there was an antlib.xml in the ant
> package.  I wouldn't mind having one that was restricted to types and
> tasks for now.

We would have to suppress loading this antlib.xml as all the tasks
and types would already have been loaded.

>
> >    - should the uris of introspection discovered nested elements be
> >      the same as the containing task
>
> I'm not sure I understand.  I think you mean whether
>
> <x:foo>
>   <bar>
> </x>

The example I gave before was this:

<ant:project
    xmlns:ant="ant:core" xmlns:ac="antlib:net.sf.antcontrib">
    <ac:switch value="${foo}">
      <ant:case value="bar">
        <echo message="The value of property foo is bar" />
      </ant:case>
      <ant:case value="baz">
        <echo message="The value of property foo is baz" />
      </ant:case>
      <ant:default>
        <echo message="The value of property foo is not sensible" />
      </ant:default>
    </ac:switch>


   <ac:if>
      <equals arg1="a" arg2="${prop}"/>
      <then>
         blab ...
       </then>
       <else>
         blab..
       </else>
   </ac:if>
</ant:project>
>
> would be associated with foo's or the URI that belongs to the default
> namespace.  I'd apply the namespace rules here.  I.e. if you want bar
> to be looked up in foo's URI space, you'd have to write
>
> <x:foo xmlns="...">
>   <bar>
> </x>
>
> Maybe I'm not understanding what you mean.
>
> > * antlib support
> >    - should <typedef resource="x"/> look for all instances of x or
> >      just the first one.
> >      + I think it should.
>
> you think it should what? 8-)

I think that it should look for all instances of x ;-)

> Could you elaborate on the impact?  Up until now it would have picked
> up only the first resource, so if we change that now, it might be
> backwards incompatible (though that's probably extremely unlikely).

The impact for antlib is that one if one had multiple jars
- say for a company set of tasks, one could use the
same namespace for the jars. This should allow allow
gracefull upgrade of the system - or to support optional or extra
tasks by just dropping the new jars in the designated lib directory.

I have put the change into ant cvs HEAD so people can play with this.

There is one small problem with this. If the default namescape is
changed from ant:core to antlib:org.apache.tools.ant, and people make
antlibs with the antlib.xml in the correct place, this could cause
auto declaration of third party tasks/types into the default namespace.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to