On Sat, 20 Jul 2002, Nicola Ken Barozzi wrote:
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...
And you can import 2 files defining the same target.
Which will be 'super' in this case ?
The firt one, as per XSL spec on imports.
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.
What if:
main.xml:
... <import file="foo.xml"/>
<import file="bar.xml" />
And both foo and bar define 'a' - which one is 'super' ?
foo:a
Mixing 'import' with 'extend' is very dangerous.
? XSL spec, that's what I follow.
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.
But in this case:
- what do you do for multiple imports
a) the first wins (current)
b) the build fails with a warning about clashing names (similar to Java), that makes it important to adopt naming conventions for imported buildfiles
- you confuse everyone - all 'imported' files will be 'super' ?
The first one.
In my proposal you can access each duplicated target by using the project name( i.e. the name of the build file in which it is defined ).
This is part of a solution. You can do both, ie super and file:target.
We can have an '<extend>' task - and require that each build extends at most one file, then what you say makes sense.
Could be a solution, and seems quite good too.
I think 'extend' would be very tricky and I doubt its usefullness, but if you really need it, it can be added - at least as an external task.
I want to ingect "behaviour", not only targets with <import>.
Say I have a master buildfile, that does all I need, *except* that I want to add a task at the end of a target it uses.
I need "extend", or rewrite all targets that call the imported ones, which is a PITA.
--
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]>
