Hello Thomas
I was about ask a very similar question when I found your thread. I'm
also having problems getting the resolve to pick up new metadata in the
repository even with checkmodified="true".
Did you solve your problem?
If not, it sounds like you've got a good standalone testcase for it,
perhaps you could use this to file a jira issue for the problem?
Regards
Ross Clewley
Laun Thomas (CI/TMP) wrote:
Thanks for the answers. Unfortunately, the problem persists.
I tried to use the same settings as suggested below (update=true,
forcedeliver=true and publishivy=true). I also checked the publication date in
the ivy.xml file in the repository as suggested. It is updated correctly.
This is my publish task:
<ivy:publish
resolver="local"
artifactspattern="dist/[artifact]-[revision](-[classifier]).[ext]"
overwrite="true"
forcedeliver="true"
update="true"
publishivy="true"/>
The build script that is retrieving the artifact:
<target name="default"/>
<ivy:configure file="../ivysettings.xml" override="true" />
<ivy:retrieve
conf="all"
pattern="${basedir}/build/lib/[artifact]-[revision].[ext]"
sync="yes"
type="jar"/>
</target>
The Ivy file of the application. The dependency is set to changing:
<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra";>
<info organisation="com.acme" module="application" revision="1.0-4711"/>
<configurations>
<conf name="all" description="All artefacts" />
<conf name="master" visibility="public" description="only published
artifacts"/>
</configurations>
<dependencies>
<dependency org="com.acme" name="library" rev="1.0-+" changing="true"/>
</dependencies>
</ivy-module>
The ivy settings shared between library and application:
<?xml version="1.0" encoding="UTF-8"?>
<ivysettings>
<resolvers>
<filesystem name="local" checkmodified="true" changingPattern=".*">
<artifact
pattern="${user.home}/.ivy2/localRepo/[module]/[artifact]-[revision](-[classifier]).[ext]"/>
</filesystem>
</resolvers>
<settings defaultResolver="local" defaultConflictManager="latest-revision"/>
</ivysettings>
I can supply a complete project to reproduce the error. A fix for this problem
would be highly appriciated.
Mit freundlichen Grüßen / Best regards
Thomas Laun
Robert Bosch GmbH
Telemedicine Platform (CI/TMP)
Postfach 11 27
71301 Waiblingen
GERMANY
www.bosch.com
Tel. +49 (711) 811-3609689
PC-Fax +49 (711) 811-51849753
[email protected]
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach,
Siegfried Dais;
Bernd Bohr, Rudolf Colm, Volkmar Denner, Gerhard Kümmel, Wolfgang Malchow,
Peter Marks,
Peter Tyroller; Uwe Raschke
-----Ursprüngliche Nachricht-----
Von: Joshua Tharp [mailto:[email protected]]
Gesendet: Dienstag, 19. Mai 2009 17:43
An: [email protected]
Betreff: Re: Cache not update
My publish task looks like this:
<ivy:publish
update="true"
artifactspattern="${o.dist.d}/[artifact].[ext]"
resolver="local"
pubrevision="${my.local.revision}"
forcedeliver="true"
overwrite="true" />
I think the forcedeliver is what you two are looking for.
On Tue, May 19, 2009 at 8:14 AM, Bieringer, Dominik <
[email protected]> wrote:
I had the same problem. I got it resolved by also updating the publication
timestamp in the ivy.xml file ;).
-----Original Message-----
From: Gilles Sadowski [mailto:[email protected]]
Sent: Tuesday, May 19, 2009 17:16
To: [email protected]
Subject: Re: Cache not update
Hi.
I have a problem when retrieving artifacts from a filesystem repository.
Ivy is always using the file from the cache even if there is a more recent
version in the repository. I tried several ways to force Ivy to update the
cache, but none of them have any effect. Therefore I assume that this is a
bug in ivy. What I tried so far:
- changing=true on the dependency in ivy.xml
- checkModified=true on the filesystem resolver in ivysettings.xml
- changingPattern=".*" on the filesystem resolver
[...]
As a workaround, I am deleting the cache before every resolve.
I have posted a message reporting this exact same problem. I had tried the
same things, and currently use the same inefficient or error-prone
workaround. Needless to say that I'm also very interested in having this
sorted out (whether bug or feature requiring some appropriate config).
Gilles
