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 Fri, 19 Jul 2002 22:32:59 GMT

costinm@covalent.net 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                   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