Re: 1.6.2: Namespace uri of nested elements

[Peter Reilly]

Dominique Devienne wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
   

wouldn't this here work?
<macrodef name="example">
 <element name="files" implicit="yes"/>
 <sequential>
    <task xmlns="URI-for-prefix-x">
       <files/>
    <task>
    <copy todir="z">
       <files/>
    </copy>
 </sequential>
</macrodef>
     

no (in ant 1.6.1) see:
http://marc.theaimsgroup.com/?l=ant-dev&m=107763945224538&w=2
   

A nested element discovered by reflection is looked up in
(1) the task's namespace
(2) the namespace associated with Ant's core, no matter what the
prefix of Ant's core may currently be and no matter what the default
namespace currently is.
And (2) would only kick in if (1) fails.
I could support this proposal.
     

Excellent!
   

Cool! I've been waiting for that ;-)
Not really, since I was lucky enough I could substitute <bm:lsync> with
<sync>, thus my <sources> macrodef element was used in tasks from the
default Ant NS. I'd like to be able to reuse such a macrodef element in
tasks from different namespaces tough (in the same macro of course).
Peter, why wouldn't Stefan alternate solution work? I don't think I
followed.
 

If by Stefan's solution, you mean the reflection description above, this 
is in essence what
that patch does.

I have another XML NS weirdness in Ant I'd like to report, before I
completely forget it (I meant to report it earlier...) It's coming from the
same "compile" macro of the other problem. Here's the definition:
   <!--
     * Define the <compile> macro...
     * @attr jaxb whether to run the jaxb schema compiler
     * @elem schemas patternset/selector of XML schemas for <jaxb>
     *       Must be part of the "antlib:com.lgc.buildmagic" namespace.
     -->
   <macrodef name="compile">
     ...
     <attribute name="jaxb" default="false" />
     <element name="schemas" optional="true" />
     <sequential>
       <!-- Compile the XML schemas into Java code, if any -->
       <mkdir dir="build/generated/@{name}" />
       <bm:jaxb destDir="build/generated/@{name}" ifTrue="@{jaxb}"
                readOnly="true" strictValidation="true"
                xjcjar="tools/jwsdp-1.1/jaxb-1.0/lib/jaxb-xjc.jar">
         <bm:schemas dir="src">
           <schemas/>
         </bm:schemas>
         ...
       </bm:jaxb>
     </sequential>
   </macrodef>
The weirdness (at least to me), comes when you try to use this macro,
because as the comment above warns, you must NS qualify the <schemas> macro
element at the point of use:
   <compile name="dsp-core" jaxb="true" ...>
     <schemas xmlns="antlib:com.lgc.buildmagic">
       <include name="com/lgc/infra/persistence/**/doc-files/*.xsd" />
     </schemas>
   </compile>
 

So according to XML rules, <schemas> in the macrodef has no NS, 

It does have an NS uri (the default one), however, macrodef ignores the 
namespace
of the nested element (a consequence of using DynamicConfigurator) so 
your use
of the macro is accepted, the important thing is that the <include> 
element is in
the buildmagic uri.

The <schemas> in the macrodef is in the <bm:scheamas> task. From the ant 
1.6.1 namespace
rules, the relection elements that can be in <bm:schemas> must have the 
uri assoicated
with the "bm" prefix, in this case "antlib:com.lgx.buildmagic". The 
macroinstance sees the
elements *after* they have been processed by xml, and will see elements 
of the form:
{antlib:com.lgc.buildmagic, include}.

It is quite confusing.
The  proposed patch will allow the following:
<bm: schemas dir="src">
  <include name="com/lgc/infra/per.."/>
</bm:schemas>
and
<bm: schemas dir="src">
  <bm:include name="com/lgc/infra/per.."/>
</bm:schemas>
ie: the nested include element may be in the antlib:com.lgx.buildmagic 
namespace uri (case 1)
or in the ant namespace. (case 2).

The following will *not* be allowed:
<bm: schemas dir="src">
  <ac:include name="com/lgc/infra/per.."  
xmlns:ac="antlib:net.sf.antcontrib"/>
</bm:schemas>

But the following will be allowed: (case 2)
<bm: schemas dir="src">
  <ant:include name="com/lgc/infra/per.."  
xmlns:ant="antlib:org.apache.tools.ant"/>
</bm:schemas>

The consequences of the change means that your macro works as 
expected/intended:

   <compile name="dsp-core" jaxb="true" ...>
     <schemas>
       <include name="com/lgc/infra/persistence/**/doc-files/*.xsd" />
     </schemas>
   </compile>

while you
*must* use the proper NS when you use the macro, otherwise it doesn't work.
I find this confusing.
Would your patch solve this too?
 

I think so, see above.
BTW, note the 'jaxb' macro attribute, and the ifTrue="@{jaxb}", and
jaxb="true" nodes. I already reported that I wished to be able to infer
whether to perform a given task when a particular macro element exists.
 

This will be something post 1.6.2.
Peter
Thanks, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


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