[EMAIL PROTECTED] wrote:
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 ) ?
Sure, this is defined.
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.
But the imported file can import and override the same target from a third file...
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" ).
Outside of the redefined "a", it should not be visible. Inside, yes, only is requested via a super.
Renaming main:a as 'super.a' and using foo.xml as override is certainly bad -
Nonono, it's the opposite.
I rename foo:a as super.a , and inside the main version I can call it via super.a.
Like overriding Java methods.
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.
Sure.
But the problem is another one.
I posted 3 explicit examples on this, please take a look and let's comment those.
(I'm going to bed now BTW, it's 0:30 here ;-)
Nicola - is this acceptable ?
There are many more issues that need to be defined...
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.
-- 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]>
