Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 10:42, Stefan Bodewig wrote:
Yes, that's one way to implement it. The tricky part starts if you
want to support polymorphism for more than one nested element.
true.
The problem exists in CVS HEAD for TokenFilter, it can take
TokenFilter.Filter and TokenFilter.Tokenizer objects. Suppose
an object implements both interfaces?. The current code
just treats it as a TokenFilter.Filter.
Say class PathThatIgnoresBuildSysclassPathToTrickGump extends Path
and you want to use it in javac which has several nested elements
that are Paths.
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
Peter
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
I don't want to use it as nested element of classpath, but as nested
element of javac.
Take classfileset/zipfileset and dependset as another example
(where you can trick me ;-).
I want to be able to be able to use classfileset as srcfileset and
zipfileset as targetfileset - or the other way around.
Stefan
RE: polymorphism (was Re: antlib)
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
I don't want to use it as nested element of classpath, but as nested
element of javac.
Take classfileset/zipfileset and dependset as another example
(where you can trick me ;-).
I want to be able to be able to use classfileset as srcfileset and
zipfileset as targetfileset - or the other way around.
Actually, peter trick may give us a hint on an easy way to achieve polimorphism.
We just need to provide a way on the basic core type implementations to delegate
all calls to a nested object (similar to what we do for refids).
With that and the roles we would get alot of functionality almost free of charge
and without any changes to the core engine (but roles of course).
Jose Alberto
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 25 April 2003 11:54, Stefan Bodewig wrote: I don't want to use it as nested element of classpath, but as nested element of javac. Why because it feels more natural? and how (from an xml point-of-view)? One of the questions that usually get us stuck 8-) classpath ant:type=PathThatIgnoresBuildSysclassPathToTrickGump or PathThatIgnoresBuildSysclassPathToTrickGump ant:element=classpath are alternatives (without any claim for completeness) with quite different consequences when it comes to the implementation side of things. Neither would require any formal definition of roles. Stefan
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Actually, peter trick may give us a hint on an easy way to achieve polimorphism. We just need to provide a way on the basic core type implementations to delegate all calls to a nested object (similar to what we do for refids). Easy from the implementation side, but is it intuitive for the user to write? copy ... fileset classfileset ... /fileset /copy condition condition true/ /condition /condition In simple non-ambiguos cases like the above this could be without the trick. copy ... classfileset ... /copy condition true/ /condition Stefan
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 14:30, Stefan Bodewig wrote: 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 ;-). A thing to note is that ant: assumes that an xml namespace is set-up, ... xmlns:ant=... 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. Peter
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 14:34, Stefan Bodewig wrote: On Fri, 25 Apr 2003, Jose Alberto Fernandez In simple non-ambiguos cases like the above this could be without the trick. copy ... classfileset ... /copy condition true/ /condition This is exactly what dynamicElement is for. For example: as ConditionBase has dynamicElement(Condition c) and as IfTask extends ConditionBase, and OutOfDate implements Condition, the following works with my build: if outofdate targetfiles path=build.xml/ sourcefiles path=build.xml/ /outofdate else echo message=build.xml is not outofdate/ /else /if Peter.
RE: polymorphism (was Re: antlib)
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
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 16:45, Wannheden, Knut wrote:
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).
Yes four different items.
I have been thinking about using namespaces with antlibs like this:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
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.
Yes, Introspection should allow constructors having Project as a parameter.
RE: polymorphism (was Re: antlib)
I have been thinking about using namespaces with antlibs like this:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
That is almost the same thing as I had in mind. Although I've been thinking
about some slight variations to this, where no top-level element like use/
would be necessary. The Jelly style would be:
project xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
.. init properies .../
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
Here target/ is still toplevel and the antlibs are loaded on project
initialization (or on demand). But I'm not sure I like this automagical
loading. Something inbetween would be this:
project
.. init properies .../
use resource=${ant-contrib.jar} ns=antlib:ant-contrib/
use resource=${antelope.jar} ns=antlib:antelope/
target name=test xmlns:antcontrib=antlib:ant-contrib
xmlns:antelope=antlib:antelope
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
knut
RE: polymorphism (was Re: antlib)
Wannheden, Knut wrote:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
Or even:
antelope:if xmlns:antelope=antlib:${ant-contrib.jar} /
In any case - if ComponentHelper is used, it'll get
antlib:/path/to/ant-contrib.jar as first param and if as the second param
- and any helper in the chain can create the task.
I don't like passing the .jar very much - but that's probably the only
way if we want to use META-INF/antlib.xml.
The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e.
descriptor in a package ), and use antlib:net.sf.antcontrib as namespace.
Then getResource() can be used, and we don't have to worry about
multiple jars providing META-INF/antlib.xml - which forces us to use the
.jar file directly.
Costin
That is almost the same thing as I had in mind. Although I've been
thinking about some slight variations to this, where no top-level element
like use/
would be necessary. The Jelly style would be:
project xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
.. init properies .../
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
Here target/ is still toplevel and the antlibs are loaded on project
initialization (or on demand). But I'm not sure I like this automagical
loading. Something inbetween would be this:
project
.. init properies .../
use resource=${ant-contrib.jar} ns=antlib:ant-contrib/
use resource=${antelope.jar} ns=antlib:antelope/
target name=test xmlns:antcontrib=antlib:ant-contrib
xmlns:antelope=antlib:antelope
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
knut
RE: polymorphism (was Re: antlib)
No need for parsing! Don't know about ClassLoader#getResources??? --DD -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] I don't like passing the .jar very much - but that's probably the only way if we want to use META-INF/antlib.xml. The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e. descriptor in a package ), and use antlib:net.sf.antcontrib as namespace. Then getResource() can be used, and we don't have to worry about multiple jars providing META-INF/antlib.xml - which forces us to use the .jar file directly.
