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).
[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.
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.
[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.
What's the expectation: is X from B executed or not?
Is it executed before or after X from A?
:-/
Oha! Caught?
We're defining it as we discuss.
Ah, ok. A dedicated effort would still be a nice idea, I think.
J.Pietschmann
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
