]
Sent: Monday, March 23, 2015 4:07 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration question
There are uses where a FileSystemRepository need to be cached for performance.
On Windows, UNC path files will be resolved by the FileSystemRepository. On
Linux, smb or NFS file
22, 2015 6:07 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration question
If you set your resolver’s checkmodified flag to true, it will verify the
timestamp of the published artifact and pull down a more recent version if
the repo is newer than the cache. I’ve found
@ant.apache.org
Subject: Re: cache busting and integration question
It's an interesting problem to investigate, and I understand your frustration.
But since we don't have exactly the same setup as you, it's not evident to tell
exactly what the problem is and how you can solve it.
We also have
Subject: Re: cache busting and integration question
If you set your resolver’s checkmodified flag to true, it will verify the
timestamp of the published artifact and pull down a more recent version if the
repo is newer than the cache. I’ve found that if you have chained resolvers,
you need to do
L.K.
-Original Message-
From: Zac Jacobson [mailto:pie@gmail.com]
Sent: Sunday, March 22, 2015 6:07 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration question
If you set your resolver’s checkmodified flag to true, it will verify the
timestamp
@ant.apache.org
Subject: Re: cache busting and integration question
If you set your resolver’s checkmodified flag to true, it will verify
the
timestamp of the published artifact and pull down a more recent version
if
the repo is newer than the cache. I’ve found that if you have chained
]
Sent: Sunday, March 22, 2015 6:07 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration question
If you set your resolver’s checkmodified flag to true, it will verify the
timestamp of the published artifact and pull down a more recent version if the
repo is newer than the cache
of the incorrect artifact for the
found artifact at the last moment, everything would work properly.
L.K.
-Original Message-
From: Marc De Boeck [mailto:mdeb...@gmail.com]
Sent: Sunday, March 22, 2015 2:30 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration question
a file
system resolver. That would be a major step forward and would make much
of this odd behavior go away.
L.K.
-Original Message-
From: Marc De Boeck [mailto:mdeb...@gmail.com]
Sent: Monday, March 23, 2015 1:29 PM
To: ivy-user@ant.apache.org
Subject: Re: cache busting and integration
: Monday, March 23, 2015 2:16 PM
To: ivy-user@ant.apache.org
Subject: RE: cache busting and integration question
We experienced this bug in sbt as well.
If I recall correctly, it turns out that the implementation of most resolvers
is rather tied to the implementation of the cache. One artifact
Please have a look at the paragraphs Dealing with integration versions in
http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html:
The typical developer workflow using SNAPSHOT builds of a release, has
become popular because it is the standard in Maven. A disadvantage of using
If you set your resolver’s checkmodified flag to true, it will verify the
timestamp of the published artifact and pull down a more recent version if the
repo is newer than the cache. I’ve found that if you have chained resolvers,
you need to do this at the top level and it affects all repos,
12 matches
Mail list logo
