ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: ant 1.5.4 : Import
Date Fri, 25 Jul 2003 06:15:58 GMT

Conor MacNeill wrote, On 25/07/2003 1.25:

> On Fri, 25 Jul 2003 01:50 am, Dominique Devienne wrote:
>>Getting back to your point, where does that leaves us for basedir?
> I've slept on it :-). I'd vote to go with the current behaviour. i.e. ignore 
> basedir. Import tasks will always import relative to the file containing the 
> import statement. Slightly different from the standard Ant file resolution 
> behaviour but a reasonable approach for <import>. In the end, since most 
> people use "." for basedir, it would not be a problem in general.
> If you want to be able to build files to only function as imports, I'd support 
> that (so called dual behaviour). In fact, I'd be tempted to use an element 
> besides <project> to make it even more explicit. Such an element would not 
> support basedir. I did that in Mutant - it was called <fragment> but it could 
> be called <import>. I wouldn't find that confusing with the <import> task
> others might - maybe <importable>
> So 
> +1 on capability to restrict a build file to only be <import>ed
> -1 to make that mandatory for <import>s
> +0 to an attribute in project to designate such files
> +1 to a new root element instead.
> Thoughts?

Interesting :-)

Here are the usecases:

  1) I have a project that is made only to be imported:
     <fragment name="">...</fragment>

     - Ant will deny the use of it standalone -

  2) I have a project that is not made to be imported:
     <project importable="false">...</project>

     - Ant will deny the use of it as imported -

  3) I have a project that can be imported or used as-is:
     <project importable="true">...</project>

     - Ant will never deny it's use -

  4) I have a project that does not say if it can be imported:
     <project importable="true">...</project>

     - Ant will never deny it's use but warn if it's imported -

I think that this is a very good idea, as it makes it possible to have 
the build writer be able to make all use cases work and still have some 
safety when the file is imported.

I'd add another thing: let's take case (1). It says that the file is 
made so that it makes correct use of absolute and relative dirs WRT 
import. But sometimes targets, and imported ones in particular *expect* 
some properties to be present, or some parameters.

In java I declare methods with the parameters they need, in Ant there is 
usually no such a check, not even at runtime.

What I can do is

  <target name="mytarget">
    <fail message="needed for blah blah blah" unless="the_property"/>


Do you think that this is all that can-should be done in these cases?
Should I add a small description of this usage in the importtask docs?
What about adding return values?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message