[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627073#action_12627073
]
Xavier Hanin commented on IVY-387:
----------------------------------
bq. if an ivy settings is served by http, using relative path would make no
sense and things should blows up
Well, it depends. If what you need is an URL like for properties loading or
settings inclusion, it doesn't need to blow up. But I agree that from a user
point of view having paths in a settings file relative to the settings file
itself is more obvious. What I dislike is having the same settings file blowing
up in one case and not in the other case.
We also need to be very careful if we choose to make paths relative to the
settings file. Indeed, if we can pretty easily handle this for resolvers using
a File attribute, the case is different for resolvers which takes a String,
which is later converted to a File. For instance a filesystem resolver takes an
Ivy pattern. The pattern is a String, which the resolver has to convert to a
File at resolution time. But currently the resolver has no idea of which
settings file was used to define it. So to resolve the pattern as relative to
the settings file, we'd need to keep this information, even for included
settings. This leads also to problems with macros. Which settings file should
be considered, the one in which the macro is defined, or the one in which the
resolver based on this macro is defined?
The more I think about it, the more I think trying to make paths relative to
the settings file is error prone. So I think I still prefer to keep it simple,
users still have the option to use ${ivy.settings.dir} to make their paths
relative to the current settings file. That being said, I won't veto if the
majority agree to have paths relative to settings file by default.
> 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.
