> 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.

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, 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?

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.

Thanks, --DD

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

Reply via email to