ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject Re: xml namespace support in ant2
Date Fri, 06 Sep 2002 22:53:11 GMT
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.

> 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.

> 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.

> 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.

> 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

 > 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".

> Hmmm... so tasks should have namespaces, targets and properties cannot, 
> since they are not elements.
Mapped to OO, tasks are classes, targets are instances (of class "target")
and so on. Another way to point out that there are differences.

 > > 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?


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

View raw message