[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568555#action_12568555
]
carltonb edited comment on IVY-387 at 2/13/08 6:32 AM:
------------------------------------------------------------
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. Also, I would
bet that most people are doing the workaround of explicitly using ${basedir} to
generate an absolute path. This approach will still work even if you change
the path resolution.
Also a problem is that except for <deliver>, most of the other Ivy tasks
already respect Ant's ${basedir} convention. If you provide a relativepath
switch, will it govern the behavior of all tasks? Can it break tasks that are
currently working, or does it just apply to <deliver>?
I say adopt the Ant standard, enforce it, and provide a prominent warning for
anyone who is currently relying on the buggy behavior.
was (Author: carltonb):
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.
Also a problem is that except for <deliver>, most of the other Ivy tasks
already respect Ant's ${basedir} convention. If you provide a relativepath
switch, will it govern the behavior of all tasks? Can it break tasks that are
currently working, or does it just apply to <deliver>?
I say adopt the Ant standard, enforce it, and provide a prominent warning for
anyone who is currently relying on the buggy 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.
