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?
IMO:
- 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
that.
Costin
>
> 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]>
