>
> 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
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 ? )
Som
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
Wannheden, Knut wrote:
>>
>><.. init properies .../>
>>> xmlns:antelope="antlib:${antelope.jar}">
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Or even:
In any case - if ComponentHelper is used, it'll get
"antl
> I have been thinking about using namespaces with antlibs like this:
>
>
><.. init properies .../>
> xmlns:antelope="antlib:${antelope.jar}">
>
>
>
>
>
>
>
>
>
>
>
That is almost the same thin
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 define
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 wit
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 dynamicEleme
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
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 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 th
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:
> >
> >
> >
> >
> >
> >
> >
>
>
> 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:
> >
> >
> >
> >
> >
> >
>
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 .
Ta
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
15 matches
Mail list logo
