ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: xml namespace support in ant2
Date Fri, 06 Sep 2002 23:38:53 GMT

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:


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"
          target X
        target X
while this is an error (if the imported X is invoked)
        target X
        target X

I 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         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message