ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: 1.6.0 + ns
Date Sat, 20 Dec 2003 09:46:38 GMT
I also find this a bit counter-intuitive Matt,
but look at it the other way around.

Before the way-NS-are-handled change in beta3, if you had a custom
task that had an addXyz(XyzType xyz), where XyzType is a custom type,
you would be doing something like:

  <my:task>
    <xyz ... />
  </my:task>

Even though xyz is defined in the AntLib of NS prefix 'my'.
This is also counter-intuitive.

To get a limited form of polymorphism, one could use the NS of
the nested element to instantiate it... Assume the 'my' AntLib
provides it's own 'enhanced' fileset declared under the fileset
type name. Doing:

  <my:task>
    <my:fileset ... />
  </my:task>

could be made different to:

  <my:task>
    <fileset ... />
  </my:task>

by instantiating a 'my' fileset instead of an Ant one. By this
scheme breaks down because the nested element name is controlled
by the add* method name, not the type of it's argument. Assume
you have a task accepting two Paths as nested elements, one for
the classpath, another for the systempath.

To have the scheme I decribe above work, you'd have to alias your
(fictitious) custom Path as both classpath and systempath. This
just doesn't scale.

The solution is the proposed ant:type attribute, which unfortunately
didn't make it to Ant 1.6. With it, you could do:

  <javac>
    <classpath ant:type="my:buildpath" ... />
  <javac>

for example, or:

  <my:task>
    <my:systempath ... /> <!-- Regular Ant Path -->
    <my:classpath ant:type="my:buildpath" ... />  <!-- Custom Path -->
  </my:task>

I hope I'm making sense.
Peter will correct me if I said anything silly ;-)

--DD

-----Original Message-----
From: Matt Benson

Okay, I confess to never having gotten around to
testing beta3.  :(  So I am just now dealing with the
"final" way of handling namespaces, particularly with
namespaced antlibs.

I have custom tasks that take nested elements of
"normal" Ant types such as fileset... pretty common,
of course.  Now, adding my antlib's namespace to
<fileset> or <mapper> i.e. <mylib:fileset>,
<mylib:mapper> seems to work but is counterintuitive
to my eye.  Is it an accident that this works?  Should
I be using Ant's default/core namespace?  What is
that?  I know I've seen some messages that alluded to
it but I can't find them now in the archives...

-Matt

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


Mime
View raw message