Re: DynamicConfigurator namespace problem

[Peter Reilly]

Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED] 

Gurr..
In making the change to remove the "uri:" portion from
the DynamicConfigurator#createElement(String) (for elements
not in the ant core namespace uri), I forgot to check all 
uses in ant 1.6.

This change breaks our old friend <macrodef/> which uses 
DynamicConfigurator to implement elements and attributes of 
the macros.  Previous to the change the following macro could 
be in an antlib:

   <macrodef name="run">
     <element name="element"/>
     <sequential>
       <element/>
     </sequential>
   </macrodef>
and used as follows:
<site:run>
   <site:element>
      <echo>Hello world</echo>
   </site:element>
<site:run>
This does not work any more.
   

Peter, I probably need to look in the code to understand this,
but can you give some hint on why is this getting broken?
I thought that it would be the other way around, i.e., <site:element>
would not be recognised by macrodef when passing "site:element"
but it would recognize "element".
 

The issue is that it should not  recognize "element" (and does not) as 
it inherits the namespace of
the task (in this case the NS URI associated with the NS prefix "site").

Maybe I do not understand how DynamicConfigurator works at all. :-(
In any case if you can give a couple of lines explanation, it would be
great.
 

In ant 1.6beta3 DynamicConfigurator#createElement(element) uses the 
component
name stringized version of the NS {URI,  local name} duple  - which is
"<URI>:<local name>" unless the URI is not specified,  or the URI is the 
ant core
URI - "antlib:org.apache.tools.ant" in which case the stringized version 
is "localname".

As ant 1.5 is not namespace aware, the above mapping works for most 
current usages of
DynamicConfigurator#createElement(element) (except that the localname 
needs to be lowered cased).

I am still all for DynamicConfiguratorNS, but do we have the time given
the
incomming release?
 

It may be possible,  provided we do not need the current prefix map as 
the execution
is done at a different time to the parsing.

We may however need another beta (it would be nice to have anyway to 
check performance
changes).

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