Jose Alberto Fernandez wrote:
Yes, as I said the problem is that no matter what is done, backward compatibity willFrom: Christopher Lenz [mailto:[EMAIL PROTECTED]
Am 11.12.2003 um 14:49 schrieb Stefan Bodewig:
On Thu, 11 Dec 2003, Erik Hatcher<[EMAIL PROTECTED]> wrote:
apologies forIt's my own fault for not tracking this closer, so my
than the onecoming 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
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?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]