Absolute and relative path

[Gilles Scokart <gs...@gmail.com>]

 

There are a few of issues in Jira concerning absolute and relative path.
Currently all the path are resolved relatively to the execution.

The different issues are :
- includes in the ivyconf files (IVY-372)
- properties in the ivyconf files (IVY-89)
- include configurations in the ivy files (IVY-347)
In all case, the path should be resolved relatively to the including file,
and not relatively to the current execution task.


There is also at least an other issue concerning the path resulutiion in ant
task parameter (IVY-232).

I think all those problems should be fixed together in order to keep ivy
more consistent.  However, there is a backward compatibility issue: some
projects (for which it is required to launch the build from the base
directory) rely on the fact that ivy use path relative to the current
execution directory.  And if they reference files that are not in the base
directory, the change will break their build.

The first project in that case is ivy itself! Try 'ant -f ivy/build.xml
test' and you will see plenty of test failing.


So I would suggest to regroup all those issues under a new one (should we
use the 'incorporate/is part of' relationship for that), and asign all of
them for a release 2.0.
 
What do you think?



SCOKART Gilles

Re: Absolute and relative path

[Xavier Hanin <xa...@gmail.com>]

On 1/12/07, Gilles Scokart <gs...@gmail.com> wrote:
>
>
>
> There are a few of issues in Jira concerning absolute and relative path.
> Currently all the path are resolved relatively to the execution.
>
> The different issues are :
> - includes in the ivyconf files (IVY-372)
> - properties in the ivyconf files (IVY-89)
> - include configurations in the ivy files (IVY-347)
> In all case, the path should be resolved relatively to the including file,
> and not relatively to the current execution task.
>
>
> There is also at least an other issue concerning the path resulutiion in
> ant
> task parameter (IVY-232).
>
> I think all those problems should be fixed together in order to keep ivy
> more consistent.  However, there is a backward compatibility issue: some
> projects (for which it is required to launch the build from the base
> directory) rely on the fact that ivy use path relative to the current
> execution directory.  And if they reference files that are not in the base
> directory, the change will break their build.
>
> The first project in that case is ivy itself! Try 'ant -f ivy/build.xml
> test' and you will see plenty of test failing.
>
>
> So I would suggest to regroup all those issues under a new one (should we
> use the 'incorporate/is part of' relationship for that), and asign all of
> them for a release 2.0.
>
> What do you think?


I like the idea to group them and address them all at once to keep things
consistent. But assigning them to a 2.0 release may postpone them for too
long: there is no current plan for 2.0. So what could be done is have a
single setting somewhere saying if relative paths resolution should be done
in backward compatible mode, or new mode. The default could even be new
mode, if it's clearly documented.

Xavier

SCOKART Gilles
>
>
>