Timestamps

[Andreas Axelsson-2]

How can I get Ivy to always set the current time as the modification time of retrieved files so that build tools relying on time stamps work correctly without having to clean and rebuild? Currently it preserves the repository time stamp.

I currently use the last RC that was out before 2.1.0.

Cheers,
/axl

[Tom Widmer-3]

Andreas Axelsson wrote:
> How can I get Ivy to always set the current time as the modification time of retrieved files so that build tools relying on time stamps work correctly without having to clean and rebuild? Currently it preserves the repository time stamp.
>
> I currently use the last RC that was out before 2.1.0.

You could possibly use a post-download-artifact trigger (in your
ivysettings.xml):
<triggers>
     <ant-call target="touch" event="post-download-artifact"/>
</triggers>

Then in your build script:

<target name="touch">
   <touch file="${file}"/>
</target>

Or something like that.

Tom

[Andreas Axelsson-2]

Unfortunately that would cause all artifacts to always be copied fresh, even if nothing has changed. The post-download-artifact trigger is called for all files even if it's not actually updated.

I guess I wasn't too clear on the distinction in my first email, but what I really wanted was to have any artifact which is replaced in my library folder to get the current time/date, regardless of the repository/cache date of the file.

I'm not actually using Ivy for a Java project, so I'm not up to date on Java programming, but I guess this could be a time to dig out the old patching skills.

I imagine a "touch_retrieved_files" option on the retrieve task would sort out my problems.

My other issue with the retrieve engine relying on dates when copying so that one cannot revert to an older version ("Retrieve fails to revert to earlier version") would have to be fixed as well, but I'm not sure if I think that should be a new option, it sounds more like a bugfix to me.

Cheers,
/axl

-----Original Message-----
From: news [mailto:news@...] On Behalf Of Tom Widmer
Sent: den 26 oktober 2009 19:29
To: ivy-user@...
Subject: Re: Timestamps

Andreas Axelsson wrote:
> How can I get Ivy to always set the current time as the modification time of retrieved files so that build tools relying on time stamps work correctly without having to clean and rebuild? Currently it preserves the repository time stamp.
>
> I currently use the last RC that was out before 2.1.0.

You could possibly use a post-download-artifact trigger (in your
ivysettings.xml):
<triggers>
     <ant-call target="touch" event="post-download-artifact"/>
</triggers>

Then in your build script:

<target name="touch">
   <touch file="${file}"/>
</target>

Or something like that.

Tom

[Felix Dorner]

Andreas Axelsson wrote:
>> How can I get Ivy to always set the current time as the modification time of retrieved files so that build tools relying on time stamps work correctly without having to clean and rebuild?
Can you give an example?

[Andreas Axelsson-2]

When I run ivy:retrieve, all dependencies that are copied to my lib folder maintains the date of the file in the cache. That means when I change my dependency to a version which has an older date, even if the revision is newer, the file won't be copied to the lib folder, as the retrieve code looks more or less like this:

foreach file in moduleFilesInCache {
   if shouldCopy(file, target) copy(file, target);
}

bool shouldCopy(file, target) {
   if !exists(targetFile) return true;
   return target.date < file.date;
}

Basically, ivy:retrieve will never copy a file with an older date over a later one, even if that's what you ask it to do.

The problem is only in the retrieve step, resolve actually resolves the correct version and copies it to the cache.

However, when Ivy populates the cache, it keeps the timestamp of the original file it downloads, at least for the FileSystemResolver. (We only use Ivy to manage our internal modules at the moment.) I'm not sure if it's the publish date or if it's the date when the file was originally built, but that makes little difference in this case. The end result is that the only way to get an older version copied to my lib folder is to clean it first.
 
IMHO, the behavior is kind of violating the principle of least surprise, when you're used to how most build tools and version control systems timestamp files on update. Compare it with your normal build rule of "build output if older than input" or when checking out an earlier version of a source repository.

Also, while going to a lower revision might be a situation that you can handle manually, by cleaning, say that I'm upgrading to a higher revision that's been built earlier than the current. It wouldn't be completely unlikely that the patch revision (e.g. 1.0.2) of a module has been published later than the next point release (e.g. 1.2.0).

Cheers,
/axl

-----Original Message-----
From: felix_do@... [mailto:felix_do@...]
Sent: den 27 oktober 2009 20:25
To: ivy-user@...
Subject: Re: Timestamps

Andreas Axelsson wrote:
>> How can I get Ivy to always set the current time as the modification time of retrieved files so that build tools relying on time stamps work correctly without having to clean and rebuild?
Can you give an example?

[carltonb]

> -----Original Message-----
> From: Andreas Axelsson [mailto:Andreas.Axelsson@...]
> Sent: Wednesday, October 28, 2009 4:49 AM
> To: ivy-user@...
> Subject: RE: Timestamps
>
> When I run ivy:retrieve, all dependencies that are copied to my lib
> folder maintains the date of the file in the cache. That means when I
> change my dependency to a version which has an older date, even if the
> revision is newer, the file won't be copied to the lib folder, as the
> retrieve code looks more or less like this:
>
> foreach file in moduleFilesInCache {
>    if shouldCopy(file, target) copy(file, target);
> }
>
> bool shouldCopy(file, target) {
>    if !exists(targetFile) return true;
>    return target.date < file.date;
> }
>

I wonder if this is related to
https://issues.apache.org/jira/browse/IVY-938


***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

[Tom Widmer-4]

Andreas Axelsson wrote:

> When I run ivy:retrieve, all dependencies that are copied to my lib folder maintains the date of the file in the cache. That means when I change my dependency to a version which has an older date, even if the revision is newer, the file won't be copied to the lib folder, as the retrieve code looks more or less like this:
>
> foreach file in moduleFilesInCache {
>    if shouldCopy(file, target) copy(file, target);
> }
>
> bool shouldCopy(file, target) {
>    if !exists(targetFile) return true;
>    return target.date < file.date;
> }
>
> Basically, ivy:retrieve will never copy a file with an older date over a later one, even if that's what you ask it to do.
>
> The problem is only in the retrieve step, resolve actually resolves the correct version and copies it to the cache.
>
> However, when Ivy populates the cache, it keeps the timestamp of the original file it downloads, at least for the FileSystemResolver. (We only use Ivy to manage our internal modules at the moment.) I'm not sure if it's the publish date or if it's the date when the file was originally built, but that makes little difference in this case. The end result is that the only way to get an older version copied to my lib folder is to clean it first.
>  
> IMHO, the behavior is kind of violating the principle of least surprise, when you're used to how most build tools and version control systems timestamp files on update. Compare it with your normal build rule of "build output if older than input" or when checking out an earlier version of a source repository.
>
> Also, while going to a lower revision might be a situation that you can handle manually, by cleaning, say that I'm upgrading to a higher revision that's been built earlier than the current. It wouldn't be completely unlikely that the patch revision (e.g. 1.0.2) of a module has been published later than the next point release (e.g. 1.2.0).

<caches checkUpToDate="false"/> prevents the uptodate check during retrieve.

Tom

[Andreas Axelsson-2]

Thanks, that solves half of my problem for now, even if it causes all files to be copied at all times.

/axl

-----Original Message-----
From: news [mailto:news@...] On Behalf Of Tom Widmer
Sent: den 28 oktober 2009 13:31
To: ivy-user@...
Subject: Re: Timestamps

<caches checkUpToDate="false"/> prevents the uptodate check during retrieve.

Tom