OK, how is the code suppose to know if something has to be
resolved based on the local basedir or the global one?
How does the user makes certain the correct choices are being taken?
What happens if I do:
ant -f build.xml -Dbasedir=mynewdir
would this affect only build.xml or also the imported buildfiles?
With respect to XSLT, the correct comparison is with the use of
the document() function and in that case you have to pass as part of
the call a parameter used to indicate which base to use when resolving
the filename of the document.
In other words we need to be able to say ${basedir}/a/b meaning the local
${basedir} and to say ${basedir}/a/b meaning the global basedir AND
${basedir}/a/b meaning the ${basedir} of some other imported file
(there is no reason why the imported cannot access thing from the
imported projects). This is why ${basedir.projname} is needed.
Of course, if for every file we need to write fullpaths then the whole
purpose of the resolvers is kind of defeated.
Jose Alberto
> -----Original Message-----
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> Sent: 09 January 2003 15:34
> To: [EMAIL PROTECTED]
> Subject: RE: Improt task and project basedir
>
>
> Jose Alberto Fernandez wrote:
>
> >> 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.
>
> I'm not very comfortable with special requirements on the
> imported files.
> Xslt doesn't - and one major use case is using existing build files.
>
> Solving the problem is easy, and it can be made customizable. All we
> need is to solve the BuildFile info in the UE and make a small change
> in the code that resolves.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
