ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: Problems with <import>
Date Fri, 19 Jul 2002 23:13:27 GMT
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 ? 

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

Mixing 'import' with 'extend' is very dangerous.


> > 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 
- you confuse everyone - all 'imported' files will be 'super' ? 

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

We can have an '<extend>' task - and require that each build
extends at most one file, then what you say makes sense.
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.

Costin


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