ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Problems with <import>
Date Fri, 19 Jul 2002 22:06:38 GMT
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: 
<project name="main">
 <import file="foo.xml" />

 <target name="a" />

<project name="foo">
 <target name="a" />

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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message