Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 3570 invoked from network); 19 Jul 2002 22:33:28 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Jul 2002 22:33:28 -0000 Received: (qmail 4904 invoked by uid 97); 19 Jul 2002 22:33:46 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 4881 invoked by uid 97); 19 Jul 2002 22:33:46 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 4864 invoked by uid 98); 19 Jul 2002 22:33:45 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D38939B.5030303@apache.org> Date: Sat, 20 Jul 2002 00:32:59 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: Problems with References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > > > > > > foo.xml: > > > > > 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 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: For additional commands, e-mail: