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}, [EMAIL PROTECTED],
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
