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
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}/
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
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
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
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
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
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
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
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
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 ...
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
12 matches
Mail list logo
