Return-Path: 
 <dev-return-48813-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 46405 invoked by uid 500); 30 Jul 2003 08:48:30 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 46390 invoked from network); 30 Jul 2003 08:48:30 -0000
Received: from main.gmane.org (80.91.224.249)
  by daedalus.apache.org with SMTP; 30 Jul 2003 08:48:30 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19hmcw-0001I9-00
	for <dev@ant.apache.org>; Wed, 30 Jul 2003 10:48:06 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@ant.apache.org
Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19hmcN-0001GH-00
	for <gmane-comp-jakarta-ant-devel@m.gmane.org>;
 Wed, 30 Jul 2003 10:47:31 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: ant 1.5.4 : Import
Date: Wed, 30 Jul 2003 10:45:48 +0200
Lines: 83
Message-ID: <bg80n3$4nj$1@main.gmane.org>
References: <747F247264ECE34CA60E323FEF0CCC0C0F5116@london.cellectivity.com>
 <200307291715.05363.conor@cortexebusiness.com.au>
 <bg596a$45o$1@main.gmane.org>
 <200307300810.29229.conor@cortexebusiness.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@main.gmane.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
In-Reply-To: <200307300810.29229.conor@cortexebusiness.com.au>
Sender: news <news@main.gmane.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


Conor MacNeill wrote, On 30/07/2003 0.10:

> On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote:
> 
>>Personally, I don't see the real need for it, as the same can be done
>>with correctly-written @importable files. In the specific, init values
>>should be included rather than imported.
>>
>>Can you point me to some relevant use-cases?
> 
> Ok, attached is a small test case which shows the failings of <import> when 
> there are target name collisions. In this case the dependency of "test" to 
> "critical" in b.xml is incorrectly replaced with a depenency on the 
> "critical" target in a.xml. 

Woah, this is a really nice test!

I strongly encourage all that are interested in <import> to unzip it and 
run it, it's very insightful.

> Target renaming doesn't help here. Having everything in a single project 
> namespace remains a problem. I'd say the number of target name collisions 
> between imported build files is going to be high because of the tendency to 
> choose target names from a small pool of common names.

Houston, I think we have a potential problem here. You are right.

I have never encountered this because I always write small imported 
files with not many targets, and each library has unique-name targets.

The issue stems from the fact that overriding works also *between* 
imported files. So what happens is that an imported file silently is 
able to override a target in another imported file without me knowing 
it, and I agree that it's nasty.

Let's see what the behaviour should be here.

multi-import(import a,b)
   target test depends=a.test, b.test

a
   target critical
   target test depends=critical

b
   target critical
   target test depends=critical


Here "critical" means a.critical to a and b.critical to b, but since 
they reference a generic "critical", they get the only one that remains 
after being redefined. The problem is that I did not redefine it in the 
main buildfile!

OTOMH this could be solved by rewriting all dependencies that are not in 
the import line.

               (1)---a
  multi-import (2)---b
               (3)---c---d

So rewriting should block collisions between (1), (2), (3), but enable 
them inside those lines.

What had been proposed is using "fully qualified" names in targets that 
I do not want to be redefined, which could be ok conceptually, but the 
issue is that the implications of sideways crosstalk between import 
lines are not transparent to the user, and thus should be avoided.

What I need is to be able to import build dependencies along with the 
targets. Probably the above solution should fix this error and make it 
work, no?

Other suggestions on how to do it while keeping the functionality that 
import now gives?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org