ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Problems with <import>
Date Sat, 20 Jul 2002 09:15:38 GMT
costinm@covalent.net wrote:
> 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message