ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Langston (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IVY-1316) ivy:retrieve Ant tasks should have overwriteMode of "always" by default, inform user when file not overwritten
Date Tue, 20 Sep 2011 20:48:08 GMT
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


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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message