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 like <my:somekindofpath/> 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. -- knut
