ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: ant 1.5.4 : Import
Date Mon, 28 Jul 2003 23:23:54 GMT
On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
> I agree that ${basedir} should be the value of basedir for the main
> buildfile being executed. But what I think is necessary is to have
> access to the basedirs of the imported file in a systematic, deterministic
> and conflict free way. I do not think we need some special "importdir"
> what we need is ${basedir.importedprojectname} and so on. This properties
> will point to the where the local basedir for that local file is suppose to
> be.
>

I think this is all getting too complex for <import>. What you are describing 
is project composition where each project maintains its own context, its own 
basedir, etc. This can be done separately from <import>. We have discussed 
this in the past as <projectref>.

In fact I would like to rename <import> as <include> to reinforce the fact 
that this is its primary function. In fact the problems we are seeing with 
import all come because it tries to do two things beyond a simple #include 
operation - target renaming and allowing imports to access resources 
according to their import file location.

The problem with <import> is that it flattens a hierarchy of project files 
into a single project but tries to preserve some of the hierarchy based on 
project names. Having multiple basedirs, ${basedir.X}, $@{basedir}, partially 
visible targets, etc is just a whole load of complexity for very little 
benefit, IMHO. 

If you want a hierarchy of projects, do that separately. If you maintain the 
hierarchy in separate project instances, you eliminate all the name clashes, 
etc.

So baed on discussions so far, my proposal would be:

1. import with optional name. The name is to be used in the renaming of 
targets.

2. Define a single property ant.import.file which is resolved at import time 
to the import location. All other properties are nt resolved.

3. All containers are <project>s for IDE compatibility. Note, however, that 
there will be some build files, designed to be imported, which will not be 
valid standal;ong build files - e.g. their targets may depend on non-existent 
targets which the importer is to provide.

4. All normal Ant operations (i.e. not imports) are resolved to the basedir of 
the outer project. There is no access to other basedirs.

5. Import specs are relative to importing file location. Don't use href as it 
creates expectations of a URL which opens up issues.

6. An attribute may be added to the <project> element to mark a build file as 
not importable.

Keep is Simple.

Conor




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


Mime
View raw message