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}, [EMAIL PROTECTED], 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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
