ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Improt task and project basedir
Date Thu, 09 Jan 2003 17:16:45 GMT
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 []
> Sent: 09 January 2003 15:34
> To:
> 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:   
> <>
> For additional commands, e-mail: 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message