ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: polymorphism (was Re: antlib)
Date Fri, 25 Apr 2003 15:45:36 GMT
This discussion starts to get interesting.  Just a few thoughts...

> >
> > because it feels more natural?
> >
> >
> > <classpath ant:type="PathThatIgnoresBuildSysclassPathToTrickGump">
> >
> > or
> >
> > <PathThatIgnoresBuildSysclassPathToTrickGump 
> ant:element="classpath">
> >
> I see. This is an interesting idea, whether is more natural 
> is debatable ;-).

It'd be natural to people who've worked with XML Schema Instance documents,
where you'd write something like:

   <classpath xsi:type="my:somekindofpath"/>

Maybe the XML Namespace like notation of "my:somekindofpath" could mean that
"somekindofpath" is a task/type defined in antlib "my".  But also something


by itself (not nested in another task) could be made possible.  In both
cases Ant would have to use the "somekindofpath" task in the antlib
registered as "my" (or actually the URI which "my" is a prefix for).

> A thing to note is that "ant:" assumes that an xml namespace 
> is set-up,
> <... xmlns:ant="...">

The way described namespaces could be used to denote antlibs.

But again, I guess these ideas are both about antlib and roles (and even
about the use of namespaces).

> Another similar idea could be:
> <classpath implementationClass="acme.ant.TrickGump" ... 
> > are alternatives (without any claim for completeness) with quite
> > different consequences when it comes to the implementation side of
> > things.
> One of the consequences is that Javac's public method 
> createClasspath()
> may need to be modified.

Yes, the addXXX() methods are probably way easier to deal with.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message