Costin Manolache wrote:
I don't know if a conclusion has been reached - but I think it is clear that we need a way to support the various
options - regardless of what default is chosen.
Well said.
The best solution ( IMO ) is to associate each UnknownElement with a Source - the file ( or URL, InputSource, etc ) that was used to read it. The source will be a lightweight Project - with basedir, name, file, etc.
Resolving relative paths will be based on the Source or Project-
based on some policy.
Yes, this is the conclusion I came to lately too.
The real problem IMO is the overloading of basedir - too many
options.
There are 2 intuitive behaviors: - resolve a relative path based on the file where it was included
- resolve it based on some base dir ( like PWD on unix ).
Since most ant files are currently using the build file as base - I think that must be the default, with explicit overrides permitted.
Disambiguating is another solution - just use a separate property
to describe the "top" file, and use it explicitly in files written
specifically for import ( like fragments ).
I'm not sure I got it... you mean that the imported file will resolve by default to the parent's basedir? Or the opposite?
MHO is that the most common usage in imported files AFAIK (to the extent of what I have used in these months), is that that paths are usually resolved relative to the parent file that imported it. In fact we found out that we needed the ant.file.projectname (resolving relative to the imported file) only after some time of using the import feature.
But I'm fine with either option.
I can start working on an impl this weekend - unless someone else wants to do it or a different solution is proposed.
Go for it, man :-D
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
