J.Pietschmann wrote:
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.
+1 I just patched my local version to accept a default 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" .../>
But we can have top-level tasks...
in http://www.w3.org/TR/xslt#extension
"
NOTE: Since an element that is a child of an Ant Project element is not occurring in a target, non-Ant top-level elements are not extension elements as defined here, and nothing in this section applies to them.
"
Hmmm...
- 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)
Which means that if they are not top-level and have a namespace that is not ant's and ant doesn't know how to handle them, it's an error.
But (changed to us Ant terminology):
"
If Ant does not have an implementation of a particular extension element available, then the element-available function must return false for the name of the element. When such an extension element is instantiated, then the Ant processor must perform fallback for the element as specified in [15 Fallback]. An Ant processor must not signal an error merely because a target contains an extension element for which no implementation is available.
"
Here it's clear that XSLT extensions rely on the fact that there are templates to structure everything, and there are no top-level things; Ant is a bit different...
So instead we could say that 1) all ant: namespace elements are core ant.
2) different namespaced elements have to be defined before use as taskdefs, typedefs or antlibs, and ant treats them accordingly
3) all namespaced tags that are not declared as in (2) must be declared beforehand as <namespacedef namespace="nms" handler="..."/>, so that the Ant ProjectHelper can use that particular Handler to process the extension. A convenient nullHandler is created when the handler is not specified.
I'd also suggest to introduce a version attribute on the project element, just in case.
+1
I'd also advice against using namespaces (more precisely: QNames) for target and property names, see below.
Currently they are used only when reqesting a property in ${}, and it may be really confusing to have them also in the names, I tend to agree.
On the other hand I can have clashes of names, but it can also be a "feature", and not a problem that cannot be resolved with good naming rules.
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
Sorry, I don't understand, can you please explain it with an Ant example? Thanks.
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.
In the embed proposal it has be superceded by prepending the name of the original project name.
But super.x can enable you to automatically collect features:
project1.a (inside it calls super.a) project2.a (inside it calls super.a) project3.a (inside it calls super.a)
If I import these three, I can have a resulting a that calls all three, since the import has collected all of them because each of them asked to be attached to the previous one.
Do you have suggestions on how to implement this in another way?
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.
Hmmm... so tasks should have namespaces, targets and properties cannot, since they are not elements.
I tend to agree.
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...
We're slowly getting there anyway ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
