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: DynamicConfigurator namespace problem
Date Thu, 11 Dec 2003 14:59:32 GMT
Jose Alberto Fernandez wrote:

>>From: Christopher Lenz [mailto:cmlenz@gmx.de] 
>>
>>Am 11.12.2003 um 14:49 schrieb Stefan Bodewig:
>>    
>>
>>>On Thu, 11 Dec 2003, Erik Hatcher 
>>>      
>>>
>><erik@ehatchersolutions.com> wrote:
>>    
>>
>>>>It's my own fault for not tracking this closer, so my 
>>>>        
>>>>
>>apologies for 
>>    
>>
>>>>coming into this late in the game.  So, createDynamicElement now 
>>>>receives more than it used to?!  So it gets "uri:elementName"?
>>>>        
>>>>
>>>... unless uri happens to be antlib:org.apache.tools.ant
>>>
>>>      
>>>
>>>>So XDoclet needs to change to work properly?
>>>>        
>>>>
>>>Probably yes - if xdoclet starts to use namespaces other 
>>>      
>>>
>>than the one 
>>    
>>
>>>for Ant's core, that is.
>>>      
>>>
>>Note that it's not the task writer who "starts to use namespaces" 
>>(apart from providing an antlib), it's the build file writer. 
>>That's an 
>>important difference to me. You can now choose to put any task/type 
>>into any namespace you want at definition time. IMHO the task should 
>>still work. Most will, but tasks based on DynamicConfigurator 
>>will most 
>>probably break.
>>    
>>
>
>The more I hear about DynamicConfigurator, the more I think it should
>be reverted (or fixed) to pass the local names only. 
>I see possible breakage to people's code. Wasn't ANTs mantra that 
>backward compatibility was of the outmost importance?
>  
>
Yes, as I said the problem is that no matter what is done, backward 
compatibity will
be broken.

I can see problems with scriptdef and using the uri:local format name.

I have no objection to passing just the localname if the other commiters
see no problem with this. - This will affect XMLFragment of cource.

>With respect to XMLFragment, I think, like others mentioned in the past,
>we need to provide a different interface (maybe extending DC) that
>provides additional methods for when NS are involved.
>  
>
Yes a DynamicConfiguratorNS interface.
Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message