RE: polymorphism (was Re: antlib)
> > Or even: > > That syntax abuses the purpose of XML Namespaces, IMO. Although a namespace is identified by an URI, I don't think attaching semantics to it is correct. Also, would ProjectHelper2 (using SAX2) resolve property references in namespace declarations? Questionable whether that should be allowed, no? IMHO it is cleaner to require explicit loading (maybe even unloading) of antlibs using a task like . That would better correspond to how works. But nevertheless, I think it's a good idea to associate a namespace with every antlib. If the antlib defines a namespace to use in its descriptor (e.g. "antlib:antelope" for antlib "antelope") then loading an antlib could be as simple as: but maybe the buildfile author wants/needs to specify the namespace URI (anything really), in which case an additional "ns" attribute could be used: Cheers, -- knut
RE: polymorphism (was Re: antlib)
Dominique Devienne wrote: > No need for parsing! Don't know about ClassLoader#getResources??? --DD I meant "open the jar, read the entry". That requires a jar to exist - if you want to package multiple libs in a jar, you need to merge the descriptors ( will this allow multiple namespaces ? ) Some people consider even getRealPath() to be a bad thing because you access the file system directly ( I disagree - but they have some points ). Regarding getResources() - you can use it to get all META-INF/antlib.xml that are visible in a certain loader. For example if you want to load all the libraries. Again, using the filesystem directly is not perfect. Costin > >> -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.
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.
RE: polymorphism (was Re: antlib)
Wannheden, Knut wrote:
>>
>><.. init properies .../>
>>> xmlns:antelope="antlib:${antelope.jar}">
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Or even:
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
> would be necessary. The Jelly style would be:
>
> xmlns:antelope="antlib:${antelope.jar}">
><.. init properies .../>
>
>
>
>
>
>
>
>
>
>
> Here 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:
>
>
><.. init properies .../>
>
>
>
>xmlns:antelope="antlib:antelope">
>
>
>
>
>
>
>
>
> which is slightly more verbose, but cleaner IMO. Especially since the
> antlib loading is explicit.
>
> --
> knut
RE: polymorphism (was Re: antlib)
> I have been thinking about using namespaces with antlibs like this:
>
>
><.. init properies .../>
> xmlns:antelope="antlib:${antelope.jar}">
>
>
>
>
>
>
>
>
>
>
>
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
would be necessary. The Jelly style would be:
<.. init properies .../>
Here 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:
<.. init properies .../>
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
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: > > > > 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 > > > > 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: <.. init properies .../> > > > Another similar idea could be: > > > > > > 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)
This discussion starts to get interesting. Just a few thoughts... > > > > because it feels more natural? > > > > > > > > > > or > > > > 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: 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 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: > > 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 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. > > > > > > > > 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: Peter.
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 14:30, Stefan Bodewig wrote: > > because it feels more natural? > > > > > or > > > 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: 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 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? In simple non-ambiguos cases like the above this could be without the trick. Stefan
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 , but as >> nested element of . > Why because it feels more natural? > and how (from an xml point-of-view)? One of the questions that usually get us stuck 8-) or 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 Friday 25 April 2003 11:54, Stefan Bodewig wrote: > 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: > > > > > > > > > > > > > > > > I don't want to use it as nested element of , but as nested > element of . Why and how (from an xml point-of-view)? javac takes five different path sub-elements - , , , and , the build xml author would always need to specify which one is to be used. I suppose one could do some thing like: > > Take / and as another example > (where you can trick me ;-). Ok :), use with (untested xml follows..) < > > I want to be able to be able to use as and > as - or the other way around. This is the same problem as javac, how does the build author specify if the fileset is a src fileset or a target fileset. Cheers, Peter
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: > > > > > > > > > > > > > > > > I don't want to use it as nested element of , but as nested > element of . > > Take / and as another example > (where you can trick me ;-). > > I want to be able to be able to use as and > as - 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: > I do not see the problem here: suppose Path implements > dynamicElement(Path path) > > one could do: > > > > > > > I don't want to use it as nested element of , but as nested element of . Take / and as another example (where you can trick me ;-). I want to be able to be able to use as and as - or the other way around. Stefan
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 which has several nested elements > that are Paths. I do not see the problem here: suppose Path implements dynamicElement(Path path) one could do: Peter
