Description
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.
Attachments
Issue Links
- is related to
-
IVY-1044 retrieve doesn't retrive files if the current one is more recent
-
- Resolved
-