[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627415#action_12627415 ] Xavier Hanin commented on IVY-387: -- Your proposition makes sense. We can allow relative paths in settings only for properties and file inclusion. All other paths (in resolvers, cache, or wherever) must be absolute, we fail settings loading if they aren't. If a plugin really wants to accept relative path, it will have to use a String attribute instead of a File attribute, and convert it to a File itself. What do other think of this solution? 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.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627440#action_12627440 ] Nicolas Lalevée commented on IVY-387: - I vote +1 ! :) 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.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627061#action_12627061 ] Nicolas Lalevée commented on IVY-387: - I agree with you, the relative path algorithm should be same every where in the file. It would be too confusing otherwise. But I have a preference of having the path relative to ivy settings file. For me it makes more sense to include other settings of properties relatively to the ivy settings file itself. Even for a cache definition or a file resolver definition. If it is relative to the basedir, then the repository and the cache will then depend path of the project, which is not a good idea for sharing an ivysettings between several projects. And then about handling relative paths to an URL, I think we should use URL.getFile(), so if an ivy settings is served by http, using relative path would make no sense and things should blows up. But if a majority agree to use the basedir, I won't put a veto on this, as having absolute path should always be used here, ivy provides the variables to fit every use case. 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.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568555#action_12568555 ] Carlton Brown commented on IVY-387: --- I think it adds too much complexity to try to keep backward compatibility. The most common use case of Ivy is from Ant. The default behavior of Ant is to execute all tasks relative to ${basedir}. Any existing scripts that don't do this are relying on a bug. For the sake of transparent maintenance, they should either be corrected to comply with Ant behavior, or if they insist on doing it the wrong way, then declare it explicitly: ant dir=. (or whatever directory they wish). This is better for the maintainers of the script because all the behavior will then be either explicitly declared or in line with Ant's implicit behavior. 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 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.