ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: ant 1.5.4 : Import
Date Tue, 29 Jul 2003 06:56:27 GMT

Conor MacNeill wrote, On 29/07/2003 1.23:

> 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. 

AFAIK this is done with <ant>....

> This can be done separately from <import>. We have discussed 
> this in the past as <projectref>.

Hmmm, I'll look in the archives.

> 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.

That was thought about, but then I looked in the XSLT spec, and import 
seems to look more like it. And it's similar to Java imports.

> 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. 

Are you talking about the current version or the proposals? IMHO the 
current version simple includes with a bit of target name rewriting.

> 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.

Import is not made to make hierarchies of projects. It's made to include 
buildfile snippets and utility finctions, not hierarchical buildfiles.

> So based on discussions so far, my proposal would be:
> 
> 1. import with optional name. The name is to be used in the renaming of 
> targets.

+1  Similar to current bahaviour.

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

+1 as now

> 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.

+1 as now

> 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.

+1 as now

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

+1 as now

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

+1 Similar to current behaviour.

So basically add:

<import file="" prefix=""/>
                ^^^^^^^^^^^^^

and

<project importable="true||false||[undefined]"/>
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Keep is Simple.

The current version is in fact made to minimize changes and keep it very 
simple, and it seems that you are coming too to my conclusions.

The problem, as you correctly note, is not about import per se, but 
about false expectations that people try to realize with it.

My question is: what are users trying to do with it that is not in his 
scope and cannot be done with <ant>?

-- 
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


Mime
View raw message