More on import: The remaining major problem is what to do if 2 targets with the same name. I'm not sure I understand the conclusion of the previous discussion or what's the expected behavior - and that's a pretty good sign that it may be a bit too complex.
What about starting with a very simple behavior - the 'main' build.xml wins (i.e. if a target with a same name is defined in an imported project, it'll not replace the original ) ? The super.super. doesn't work very well IMHO - I think the normal use is to use the imported build.xml as a library, and the main xml ( i.e the most explicit ) should win. The same happens in XSLT. The only remaining question is how ( if ? ) we access the child targets that are overriden. I would choose 'no access', but if we really want to I would use a name based on the imported file name. That means: main.xml: <project name="main"> <import file="foo.xml" /> <target name="a" /> </project> foo.xml: <project name="foo"> <target name="a" /> </project> The second 'a' target will either be ignored ( my choice ) or be made available as "foo.xml:a" ( alternative: use the foo project name, i.e. "foo.a" or "foo:a" ). Renaming main:a as 'super.a' and using foo.xml as override is certainly bad - what if you have a bar.xml declaring a ? XSL would execute main.xml:a, and that's the most intuitive and reasonable use case, you don't want an included to override what you explicitely define. Nicola - is this acceptable ? Everyone else - most of this can be implemented in a task, but there are few things that need to be in ProjectHelper. If we agree to make <import> part of ant1.6, I will leave the code in, if not - I'll just add a hook. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
