[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627028#action_12627028
]
Xavier Hanin commented on IVY-387:
----------------------------------
I've just resolved IVY-232, but I'm not happy of how we handle relative paths
globally. With current trunk we have:
* relative paths for properties and settings file in a settings file are
relative to the settings file itself (see IVY-372 and IVY-89)
* relative paths for configurations inclusion are relative to the Ivy file
defining the inclusion
* all other paths are relative to what is called Ivy settings basedir, which is
by default the current execution directory, except when run from Ant, where it
is the Ant basedir
This means that relative paths for File attributes on resolvers and caches, for
instance, are relative to the basedir, not the settings file.
So if you have:
{code}
<ivysettings>
<include file="relative/path/to/ivysettings2.xml" />
<caches repositoryCacheDir="relative/path/to/repository" />
</ivysettings>
{code}
Then the first relative path is relative to the settings file, the second is
relative to the basedir. While I first considered unifying this by making all
paths in settings file relative to the settings file itself, I realized this is
not possible, because the settings can be loaded using an URL. To load
properties or other settings it's not a problem because we can actually load
them using an URL, but this is not possible to convert a generic URL to a File.
So I don't know what's the best solution. IMO, the easiest to implement and the
most uniform would be to make all paths in the settings relative to the
basedir. In this case people who want to use paths relative to the settings
file have to explicitly put ${ivy.settings.dir} before their path. This is
slightly less user friendly.
Another solution is to keep things as is, but I really don't like it.
Yet another solution is to make all paths in settings file relative to the
settings file as long as the settings are loaded as a file. In other cases, it
would be relative to basedir. I don't like this solution either, because the
behavior then depend on how you load your settings.
So I'm definitely in favor of #1, but maybe some have other ideas or other
opinion.
> Absolute and relative path
> --------------------------
>
> Key: IVY-387
> URL: https://issues.apache.org/jira/browse/IVY-387
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 1.4.1
> Reporter: Gilles Scokart
> Assignee: Gilles Scokart
> Fix For: 2.0-RC1
>
>
> 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.
> Comment from Xavier on the mailing list :
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
