ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Improt task and project basedir
Date Thu, 09 Jan 2003 18:11:19 GMT
Jose Alberto Fernandez wrote:

> OK, how is the code suppose to know if something has to be
> resolved based on the local basedir or the global one?

- default = resolve based on the local basedir ( so all existing build.xml
can be imported and will behave as expected )
- explicit override = an attribute to import that allows you to override
the basedir.

In all projects that I know, the basedir is used to resolve files relative
to the location of the build file - and I think the default should reflect 


> 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