You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Costin Manolache <cm...@yahoo.com> on 2003/01/22 19:31:36 UTC
Import basedir
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.
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.
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 can start working on an impl this weekend - unless someone else
wants to do it or a different solution is proposed.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Nick Chalko <ni...@chalko.com>.
+1
This seems the reasonable choice.
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.
>
>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.
>
>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 can start working on an impl this weekend - unless someone else
>wants to do it or a different solution is proposed.
>
>Costin
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Costin,
While we are on the subject of <import> have you had any chance to look at
the import tests that I added which fail?
Thanks
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
> On Wed, 22 Jan 2003, Costin Manolache <cm...@yahoo.com> wrote:
>
>> 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.
>
> I'm not sure I understand what you mean.
>
> All ant files use the build-file's basedir as base 8-) - if they don't
> specify a basedir attribute, this is implicitly set to the directory
> the build file is located in. So to avoid confusion, the basedir
> attribute, if present, should be taken into account.
I know. That's the current behavior, and it needs to be supported:
- an explicit basedir in import
- the basedir attribute of <project>
- the location of the imported build file ).
What I'm trying to say is that "intuitive" ( IMHO ) is one of the 2 -
relative to the location of the file where the relative path is found,
or relative to some global basedir.
Pre-import, all relative locations where based on the location of the
file where they were used ( unless overriden by an explicit basedir )
If the default will be "single basedir ( of the importing file )" - then
we need a way to override this for older files.
If the default will be "base on the basedir/location of the imported file" -
then it is very easy to override with a basedir in import.
<import file="foo/bar.xml" basedir="foo" > will be used in the
default is "importing file basedir", if we want to use bar.xml location
<import file="foo/bar.xml" basedir="${basedir}" > will be used if the
default is "use imported file basedir" and we want to use change to use the
importing basedir.
Or better <import file=.. useBaseDir="child|parent" />.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 22 Jan 2003, Costin Manolache <cm...@yahoo.com> wrote:
> 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.
I'm not sure I understand what you mean.
All ant files use the build-file's basedir as base 8-) - if they don't
specify a basedir attribute, this is implicitly set to the directory
the build file is located in. So to avoid confusion, the basedir
attribute, if present, should be taken into account.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Nicola Ken Barozzi wrote:
>
>
>>One thing that we would appreciate is the possibility of prefixing all
>>imported properties-tasks-classpaths-etc (all things created in the
>>import) with something to prevent clashes. Maybe namespace?
>
>
> If we want to keep it simple - no :-)
>
> It seems most people believe import will be used only with files
> specifically written for import - if this is the case, and they are able
> to deal with the importing file basename, they should also use prefixes in
> their own properties and tasks.
It's about having it simple. It's much easier to just tell import to
prefix all than to have to do it yourself. It's done in other Ant tasks,
ans it's a common use case.
> Even the current target rewritting seems wrong - instead of coding with
> the mangled names, it would be simpler to just rename the imported targets (
> or use prefixed names in the build fragments).
>
> If this is the conclusion ( and I have to admit - I now agree with Conor and
> all other that simpler is better, at least for the first iteration of
> import ) - probably it would make sense to remove the mangling code, we can
> add it in ant1.7 if it proves it is really needed.
I can tell you it is. Fundamental.
I use this import every day. For me, this is Ant 1.7 ;-)
The fact is that import has two functionalities:
- import targets
- import *dependencies*
Let me try to explain what this second point means.
If you think that you will be importing targets that don't have a
depends="", I agree with you, mangling is not needed.
But what I do, is to import a file that has not much functionality, but
targets that have dependencies.
So I can /redefine/ a target that is already called by other targets,
since the name is the same!
If I import
- target compile
- target package depends=compile
now I can simply redefine
- target compile
And if I call the target package, it uses the /redefined/ target "compile".
This is a common use-case, and I'd like to retain this functionality.
IMHO *minimal* import functionality is Ok now.
That said, sugar can be added on top of it. Prefixes for example are
nice sugar (as basedir is for normal ant files, or prefixes in property
files load).
From the active usage we've been doing in these months, I can say that
(VUS= very useful sugar;
US = useful sugar;
MUS = marginally useful sugar):
- (MUS) resolving to basedir for imported tasks
- (US) basedir.importedprojectname property
- (VUS) prefixing imported stuff names
You can take my word for it or use import for three months, you choose ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Costin Manolache <cm...@yahoo.com>.
Nicola Ken Barozzi wrote:
> One thing that we would appreciate is the possibility of prefixing all
> imported properties-tasks-classpaths-etc (all things created in the
> import) with something to prevent clashes. Maybe namespace?
If we want to keep it simple - no :-)
It seems most people believe import will be used only with files
specifically written for import - if this is the case, and they are able
to deal with the importing file basename, they should also use prefixes in
their own properties and tasks.
Even the current target rewritting seems wrong - instead of coding with
the mangled names, it would be simpler to just rename the imported targets (
or use prefixed names in the build fragments).
If this is the conclusion ( and I have to admit - I now agree with Conor and
all other that simpler is better, at least for the first iteration of
import ) - probably it would make sense to remove the mangling code, we can
add it in ant1.7 if it proves it is really needed.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Conor MacNeill wrote:
>
>>So, what do you think - keep it simple :-)
>
> Good argument. You almost convinced me.
>
> There is only once concern I still have - "keep advanced/harder things
> possible". I see no way to support the use case that actually
> get me into this issue.
>
> If I import a file - I just can't reffer to files relative to the imported
> file. Even if I use absolute paths - there is no way to construct them,
> unless the location of the imported file is not available.
<dirname property="imported.dir" file="ant.file.importedprojectname"/>
This is why I asked it to be included 8-)
> But I'll try to see how this can work: let the import be simple, and
> use "basedir.PROJECT_NAME" and rewrite all the build files to use this.
We did it with Centipede projects and it basically fills all our needs.
One thing that we would appreciate is the possibility of prefixing all
imported properties-tasks-classpaths-etc (all things created in the
import) with something to prevent clashes. Maybe namespace?
> Probably I'll need some way to hack that so the build files will still
> work with 1.5.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Costin Manolache <cm...@yahoo.com>.
Conor MacNeill wrote:
> So, what do you think - keep it simple :-)
Good argument. You almost convinced me.
There is only once concern I still have - "keep advanced/harder things
possible". I see no way to support the use case that actually
get me into this issue.
If I import a file - I just can't reffer to files relative to the imported
file. Even if I use absolute paths - there is no way to construct them,
unless the location of the imported file is not available.
But I'll try to see how this can work: let the import be simple, and
use "basedir.PROJECT_NAME" and rewrite all the build files to use this.
Probably I'll need some way to hack that so the build files will still
work with 1.5.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import basedir
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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.
>
Costin,
My thoughts:
I think the <import> proposal is being overloaded with two concerns. A basic
inclusion mechanism for build files which are suitable for inclusion and a
more complex mechanism to compose independent builds into a single build
context.
Trying to do the latter with import is probably not a good idea as it really
requires multiple independent project instances within the build context.
Renaming and prefixing things seems to me a kludge to fit this all into a
single project context. The chance of interactions and collisions is very
high. The whole basedir question is a symptom of this problem.
My preference, therefore, would be to keep things simple and use import as
mostly a simple inclusion mechanism. The only basedir of importance in this
case would be the top level project being run. All properties and paths
would be resolved relative to this basedir regardless of the basedir of the
project actually containing the task definition.
The renaming of clashing targets is something I have not looked into yet in
much detail - it sounds useful for creating build templates and overriding
generic build steps but perhaps this too should be removed in favour of
simplicity.
I think a simple inclusion mechanism is still very useful. The builds have
to be defined with inclusion in mind but this is not a bad thing.
So, what do you think - keep it simple :-)
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>