ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [Bug 28444] - Import: Target Handling Bug
Date Fri, 13 May 2005 13:11:44 GMT
Nicola Ken Barozzi wrote:
> Steve Loughran wrote:
>> Phil Weighill-Smith wrote:
>>> I missed the beginning of this thread but just want to say that I 
>>> personally think that import is the best feature in Ant today (apart 
>>> from Ant's being in the first place, that is)!
>> I find it hard to work with in a big project.
>> problems
>> -risk of adding a new target in an imported build file conflicting 
>> with one in the importer (i.e. lack of private scope)
>  >
>> -when you override a target, you dont get access to its dependents. 
>> Workaround: many pseudo-targets that only model dependencies.
> Could you please explain more? TIA

Imagine I have a base build file with a target "compile". If I overwrite 
it in a project, I need to manually redeclare all dependencies of the 
compile target


<target name="compile" depends="init,compile-classpath" >...</target>


<target name="compile" depends="init,compile-classpath,generate" 

That is, I need to know and declare the dependencies again. If I change 
the dependencies of the base target, all derived files need updating. 
What I want to say is

<target name="compile" depends="dependencies(base.compile),generate" 

The workaround is pseudo targets

<target name="pre-compile" depends="init,compile-classpath" />

<target name="compile" depends="pre-compile" >...</target>

and then depend on the pre-compile target in derived build files

<target name="compile" depends="pre-compile,generate" >...</target>

>> -once you have sub-projects importing ../../common.xml, they are no 
>> longer self contained, which makes it harder to work with outside the 
>> existing build tree.
>> I dont see any good solution for the latter.
> The first and the last "problems" are in fact worksforme, as the import 
> task is *intended* to pollute the project files that use it to be able 
> to work as needed.

yes, but I dont always want to pollute project files with my inner 

> In most cases, one would want to use <typedef>, <macrodef> or <ant>

> instead of importing buildfiles with <target>s, which should be used 
> only to reuse and "extend" a base buildfile.

macrodef/presetdef defines standard actions; the base buildfile defines 
the standard process.

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

View raw message