From dev-return-74125-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Thu Aug 31 15:51:17 2006 Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 7311 invoked from network); 31 Aug 2006 15:51:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 Aug 2006 15:51:16 -0000 Received: (qmail 25528 invoked by uid 500); 31 Aug 2006 15:51:15 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 25488 invoked by uid 500); 31 Aug 2006 15:51:15 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 25476 invoked by uid 99); 31 Aug 2006 15:51:15 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Aug 2006 08:51:15 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ddevienne@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Aug 2006 08:51:14 -0700 Received: by nf-out-0910.google.com with SMTP id a4so528574nfc for ; Thu, 31 Aug 2006 08:50:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dmiWerQew/8HCVQiWdCbpzGUL5SBQNv6DBX5S+4eJBybUCC/EKe0T+unLUccfFmer0E4kvI0wiD1K9fnThLD6Spej9z48FTmfgmV98/e39sDryFQx8PYphoX1bUBzcoSDOuRzfZAEXBfoCIjxNg2rTmCQy4PmNQQbWXVKqMn2LA= Received: by 10.49.75.2 with SMTP id c2mr1590176nfl; Thu, 31 Aug 2006 08:50:52 -0700 (PDT) Received: by 10.49.64.15 with HTTP; Thu, 31 Aug 2006 08:50:52 -0700 (PDT) Message-ID: <255d8d690608310850w65e2d464l830940a39c00612b@mail.gmail.com> Date: Thu, 31 Aug 2006 10:50:52 -0500 From: "Dominique Devienne" To: "Ant Developers List" Subject: Re: copying references In-Reply-To: <20060831152636.10563.qmail@web55105.mail.re4.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <255d8d690608310811t63cd53d0wc1c81f35f859debc@mail.gmail.com> <20060831152636.10563.qmail@web55105.mail.re4.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > I agree it's diserable, but it's indeed not currently possible to override a reference and at the same time reuse the previous definition, if any. You can do the override alone, albeit with a warning. This is hurting Ant's ability to define generic and reusable build files. When I designed a generic build for my previous companie's projects, I really wished for the ability to use a -like tag that 'inserts' the overriden target or id'd type. > In the commented zone above, the following creates a > circular reference: > > > > > > > Yep, obviously. > This doesn't yield the desired result either: > > > > > > > Why doesn't this work? It should, no? Sure, having the use a new id is not great, but... > > You should still get a circular reference because of > the way references are resolved. Yep, circular it is. > The only way is: > > > > > > > > > > > Is there another way, without code (I know, code is > not necessarily the most evil thing in the world...)? Hmmm, I'm not fond of this notation. I see where you are going with this, and it would indeed solve the problem at hand, and even the problem generally, but it's still kinda ugly and hacky to me. This all boils down to me to the lack of compartimentation of references in the context of import. We introduced compartimentation of target by allowing to reference them using the . composed name, and allowing silent override of imported targets. (FTR, I was against using . and would have preferred using a build-specific private name to refer to imported build file artifacts) Having of compartimentation of references in the context of import would avoid the need of I think, as you could always refer to an imported reference thru its composed name, and override (hopefully silently) the non-composed name with the new definition. Am I making sense? --DD --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org