> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
>
> 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.
>
Is <import> to support target overriding? If it does, then
we are talking about <import> if it does not (i.e., targets in
importing and imported files with same name causes ERROR) then
we are talking about <include>.
> 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.
>
As long as I have a way to specify relative <import>s I have no issue.
>
> 1. import with optional name. The name is to be used in the
> renaming of
> targets.
>
Fine, but then this is not <include> it is <import>. :-)
> 2. Define a single property ant.import.file which is resolved
> at import time
> to the import location. All other properties are nt resolved.
>
This one you need to explain better. What does it mean resolved at import time?
Can I mention this property inside a target of the imported file?
If I can, would it be set to the expected value when the target is later
executed?
Otherwise, would the lifespan of the property be the import action itself?
That may mean the property will be set while executing top-level targets
And if I want to preserve the value I need to save if on my own properties.
If the "otherwise" is what you mean, then fine. But I would prefer having
the local basedir (or the file dir) because one usually need to refer
to other relative files and not to the build file itself. It makes no sense
to force users to do file arithmetic when it is not necessary.
(I vote for keeping "ant.import.basedir") which applies all the basedir rules
as we have them today.
> 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.
>
With the caviat that during importing I can have access to
the ant.import.basedir and can save it on my own properties
if I need to.
> 5. Import specs are relative to importing file location.
> Don't use href as it
> creates expectations of a URL which opens up issues.
>
Yes, that is fine. As long as I can say file="${basedir}/xyz" (for
an import from the top) or file="${ant.import.basedir}/xyz" (for an
import from the local basedir).
Imports can only be at top level, right?
> 6. An attribute may be added to the <project> element to mark
> a build file as
> not importable.
>
I really do not see the need for this. It seem superfluous.
How many of you scan their disks for build.xml files to execute
without knowing what they do?
> Keep is Simple.
>
Yes.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
