On Fri, 24 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
>> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>> > - should the uris of introspection discovered nested elements
>> > be the same as the containing task
> 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" />
is not defined IMHO, as we don't have a default namespace at all.
It would be Ant's core URI if that was the URI of the default
namespace in the current scope and AntContrib's if it was theirs.
> <ac:if>
> <equals arg1="a" arg2="${prop}"/>
> <then>
> blab ...
> </then>
> <else>
> blab..
> </else>
> </ac:if>
Assuming Ant's core URI was associated to the default namespace, you'd
have to use ac:then and ac:else.
>> > * 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 ;-)
I agree that it should do so for the XML style - but I'm not sure
about property files as <typedef resource> is there since 1.4 for them
and has always only loaded one file.
> 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.
Didn't we want to allow this anyway? I mean allow people to add tasks
to the core namespace as traditional <taskdef> would do so as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
