[
https://issues.apache.org/jira/browse/IVY-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799403#comment-13799403
]
Stephen Haberman commented on IVY-1316:
---------------------------------------
Maarten: why do we care about backwards compatibility here? I'm having a hard
time understanding when Ivy keeping a file that is no longer the right one
would be a good thing.
On our team, it's only led to confusion and people saying "Ivy sucks" because
what works on one machine (that has retrieved and gotten a newer jar) is
different from on another machine (that is doing a new retrieve and so gets a
different jar).
This sort of non-determinism makes users hate build systems and I think we
could make a pretty strong case for either removing overrideMode out right, or
changing the default to different.
(If we kept it, and highlighted in the release notes it changed, then any
masochists who preferred the old behavior could keep it, but we'd stop new
users from being surprised/burned by this surprising behavior.)
> ivy:retrieve Ant tasks should have overwriteMode of "always" by default,
> inform user when file not overwritten
> --------------------------------------------------------------------------------------------------------------
>
> Key: IVY-1316
> URL: https://issues.apache.org/jira/browse/IVY-1316
> Project: Ivy
> Issue Type: Improvement
> Components: Ant
> Affects Versions: 2.2.0
> Reporter: Brett Langston
> Labels: ant, retrieval
>
> The Ant ivy:retrieve task defaults to overwriting the destination file only
> if one with a more recent timestamp is available (overwriteMode="newer").
> Moreover, if it decides not to overwrite, it informs the user that the
> artifact was retrieved, even though it wasn't. This default behavior and
> incorrect retrieval message caused us a bit of pain today.
> These are the two main problems, with some possible solutions:
> 1) Even though the ivy.xml file specified the desired revision, it was not
> retreived because the desired revision had an older timestamp than what the
> user already had. This will happen constantly in the scenario where the user
> is changing their ivy.xml file to work with an older version of an artifact.
> Why is it assumed that the user will only be pulling down newer and newer
> artifacts? It is quite common to want artifacts with older timestamps than
> what you are working with at the moment. The default value of
> overwriteMode="newer" for the ivy:retrieve task is surprising, and goes
> against the default behavior of any other file utilities I can think of.
> Proposed solution: Make the ivy:retrieve overwriteMode="always" be the
> expected default. After all, if I tell Ivy to retrieve something, I expect
> it to be retrieved! It makes much more sense to override this behavior only
> in the case where the "newer" behavior is wanted, not the other way around.
> 2) The ivy:retrieve Ant task told us that the higher version had been
> retrieved, even though it was not.
> Proposed solution: If Ivy is going to decide not to retrieve an artifact due
> to the overwriteMode setting, it should inform the user that the desired
> version was found, but that it was not used due to the overwriteMode.
> Otherwise, the user (rightly) assumes that if Ivy says an artifact was
> retrieved, it was, indeed, retrieved.
> In summary, we might have shipped the wrong version of an artifact, just
> because the ivy:retrieve task didn't give us the version we asked for due to
> an older timestamp. It seems like a default overwriteMode of "newer" is very
> dangerous (especially since the user isn't informed of the lack of
> overwrite), and that a default overwriteMode of "always" is the more expected
> behavior when requesting a file to be placed somewhere.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
