> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
>
> Conor MacNeill wrote:
> > Jose Alberto Fernandez wrote:
> >
> >>
> >> This seem to be a not so simple issue.
> >
> > Indeed. As I've thought about it more, I wonder what we
> should be doing
> > here. All the other tasks in the imported build file will
> be resolving
> > relative to the basedir of the importing build, not the
> build in which
> > they are defined. Is that good? I feel it may cause some
> problems, some
> > unexpected behaviour.
>
> This is the reason why I asked to introduce the ant.file.projectname
> property, that gives me the real path of the imported build.
>
I think we also have now basedir.projectname which should be based
on the value of the basedir attribute for that project. So in the
following situation:
file: /a/b/c/build.xml with
<project name="x" basedir="../base"/>
we want basedir.x="/a/b/base".
> To solve the problem we could add a importable="true"
> attribute to the
> project. We can post a message that warns that it's not marked as
> importable, and if the build fails and a file was imported,
> we can add
> to the message a note that tells the user that the file that was
> imported was not marked as importable.
>
I like this, but I would be even more strict, the project must be
"importable" in order to be imported, and this also would make
${ant.file.projectname} and ${basedir.projectname} available.
This will force an specific clear pattern for the imports and will
make users more aware of the suttle diferences on file resolution rules.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
