ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: xml namespace support in ant2
Date Mon, 09 Sep 2002 20:07:38 GMT

J.Pietschmann wrote:
> Nicola Ken Barozzi wrote:
> 
>>> [top-level tasks]
>>
>> It has been accepted, and personally I find it very useful; I am able 
>> now do do all sorts of initialization stuff, also in imported files, 
>> and for example I can xslt-transform a project before importing it.
>> It's quite powerful, and not confusing at all.
> 
> 
> As for XSLT-then-import: what's the advantage over
>  <project ...>
>     <target name="default"
>        <style src="..." dst="build2.xml" .../>
>        <ant src="build2.xml">
>     </target>
>  </project>
> (sorry, can't be bothered looking up the correct syntax).

It's a big difference, because in your example you setup a new instance 
of ant and it *really* slows down things, and also you create it a 
nested context, not in the same context in which other tasks are run.

For example, with xslt I am able to construct a classpath using complex 
logic quite easily, and import it in the buildfile right away as a 
toplevel reference, where everyone can use it.

Basically it's preprocessing, like there is in C code, only that it's 
done at runtime, not in two steps.

>>> [QNames]
>>
>> This is the current use:
>>
>>   ${jxpath:/references/}
>>   ${velocity:$mystuff}
>>
>> They tell Ant that the property must be resolved not directly but 
>> using a defined interceptor; sort of the protocol in inet urls.
> 
> 
> If the semantic of the jxpath prefix is hardwired or defined by
> something like
>   <bind prefix="jxpath" handler="whatever.class.necessary.Handler"/>
> it's ok.
> If it aquires it's semantic by
>   <project xmlns:jxpath="http://xmlns.abuse.org/ant">
> then it's abuse.

I'm safe then =;-)

     <taskdef classname="org.apache.tools.ant.taskdefs.optional.JXPath"
              name="jxpath" />
     <jxpath/>

> Note that it would be legal to have the namespace declaration above
> if it doesn't define how ${jxpath:/references/} is interpreted, for
> example in case someone wants to have a <jxpath:mytask> somewhere
> (though this is hardly recommended). I hope you see the pattern.

Yes, I do now.
Fine then, it's ok.

>>> [scoping rules] [property namespaces] 
>>
>> Any more concrete hint on how these should be?
> 
> Ahem, perhaps using ${project-name.property-name} or something.
> Every method other than using xmlns:scope-name="..." would be fine.

Ok, rom the above I think I now get what you mean.

>>> What's the expectation: is X from B executed or not?
>>> Is it executed before or after X from A?
>>
>> :-/
> 
> Oha! Caught?

Yes.
I think you are right, we must avoid including multiple times the same 
target from different files in the same file.

>> We're defining it as we discuss.
> 
> Ah, ok. A dedicated effort would still be a nice idea, I think.

You've found yourself an occupation then I guess ;-P

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message