ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maarten Coene (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IVY-1316) ivy:retrieve Ant tasks should have overwriteMode of "always" by default, inform user when file not overwritten
Date Sat, 05 Nov 2011 07:32:51 GMT

    [ https://issues.apache.org/jira/browse/IVY-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144624#comment-13144624
] 

Maarten Coene commented on IVY-1316:
------------------------------------

1) The default overwriteMode was set to 'newer' for backwards compatibility reasons.
2) I agree the log message should be more clear when an artifat is not retrieved
                
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message