J.Pietschmann wrote:
Nicola Ken Barozzi wrote:
But we can have top-level tasks...
So called top-level tasks should only set properties, import stuff, define file sets and such and perhaps do a few other selected things. All Ant elements. Allowing arbitrary commands at top level is a bad idea, one reason being the problem of nailing down a sensible execution order if there are arbitrary side effects. This has been argued up and down, so I'm not going to start this again. It's going to correct itself anyway.
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.
Simply top level tasks are basically preprocessors based on ant tasks.
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 stick with binding classes to the task's QName for a while. For example, it seems to be a bit of an overkill to write a handler class just for adding a single task. Add the handler later if necessary.
"that are not declared as in (2)"
Tasks are to be declared more simply.
Handlers are to make it possible to add features to Ant that are not in the default concepts (like the doc namespace youtalk about).
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.
Using QNames for something else than element or attribute names is *abuse*. After all, the prefix is bound to an *XML* namespace, not a property namespace or something.
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.
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.
If clashes prove to be a problem, and can't be cured by resonable scoping rules, some sort of namespaces may have to be introduced, but *don't* use XML namespaces for this purposes. Invent property namespaces if necessary.
Any more concrete hint on how these should be?
Sorry, I don't understand, can you please explain it with an Ant example? Thanks.
This was an Ant example main file main importA imports file importA importB importA imports file importB target X importB declares target X target X importA declares target X
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 XI think I understand now.
You mean that a file can import a defined target only once; that is once per file, it also applies to the imported file itself.
Ok, fine with me.
> But super.x can enable you to automatically collect features:
Automatic collection may cause unintended behaviour:
main imports A
A imports B
B declares X
A declares X, but does not call X imported from B
main imports B
somewhere in main super.X is called
What's the expectation: is X from B executed or not?
Is it executed before or after X from A?
:-/
I have the feeling that having exactly one imported target executed and multiple matches reported as error will prevent nasty surprises. For example I think I can construct a circular dependency which can only be detected after some tasks have already been executed. I'll try a bit harder tomorrow.
Also, I'm not too fond of the inflation of small expression languages (comma separated lists, dot separated names...) [BTW, is whitespace allowed around the dot?]. And I like to be able to process such expressions easily with current XSLT processors, in a portable way. Comma separated lists qualify nearly but not quite for "easy".
Example please.
...
> > write a complete specification > We're slowly getting there anyway ;-) Sorry? I seem to be missing something...or is it just too slow to notice?
We're defining it as we discuss.
--
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]>
