Peter Donald wrote:
I don't think there is any plan for it at this stage. There are too many
potential uses of namespaces and associated confusion. Do you namespace;
* property names
* types (aka tasks, datatypes, condtions, etc)
* property evaluation (ie "${javascript:performMagic()}"
* target names (ie if you depend on foo:bar target will that execute bar
target in foo project?)
* aspects (ie add ant:fail-on-error="true" to all tasks)
There are existing XML related specs using namespace. Perhaps
part of Ant's usage can be modeled after XSLT:
- Core: All elements defined by the Ant core specification are
in the Ant namespace.
- Top level: Elements which are immediate children of the
document element ant:project and which are not in the
Ant namespace must be namespace qualified and in some other
namespace. If the processor doesn't know how to handle such an
element, it is silently ignored.
In XSLT, such elements are used for putting arbitrary data
and documentation into the file:
<ant:project xmlns:ant="http://ant.apache.org/2002/buildfile";
xmlns:doc="http://some.other.org/simpledoc";>
<doc:propdoc>
<p>The property <propname/> is set if the XYZ class
is available on the classpath</p>
</doc:propdoc>
<ant:property name="avail.xyz" .../>
- Extension elements: All other elements which are not in the Ant
namespace must be in some other namespace, and it is an error if
the processor does not know how to handle them unless they are
in an ant:fallback element (or something similar)
(see http://www.w3.org/TR/xslt#extension for details)
I'd also suggest to introduce a version attribute on the
project element, just in case.
I'd also advice against using namespaces (more precisely: QNames)
for target and property names, see below.
As for target name scopes which become relevant for imports I'd
use the import tree approach roughly like XSLT does: the import
tree is traversed until a target is found, the subtree of this
node is skipped and the tree is traversed further, if there is
a second match, an error is thrown.
This means the following is ok, because X in B is "shadowed"
main
importA
importB
target X
target X
while this is an error (if the imported X is invoked)
main
importA
target X
importB
target X
Kludges like "super.X" should be avoided, partly because "super"
is hard to define both intuitively and reasonably contradiction-free,
partly for possibly clashes with a user defined target which happens
to have the name "super.X", and also for other reasons.
As for using namespaces for scoping targets: the role of namespaces
is to avoid name clashes for XML *elements*, therefore encouraging
aggregation of XML from various vocabularies and fostering reuse
of existing vocabularies. The scope for targets are projects, not
XML vocabularies. Same goes for property names.
From time to time I ponder to write a complete specification for
Ant build files and perhaps a proper processing model, unfortunately,
this is quite time consuming and motivation is low...
J.Pietschmann
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
