Hello, Did this issue ever get solved?
Cheers! - Georges -----Original Message----- From: Laun Thomas (CI/TMP) [mailto:[email protected]] Sent: Wednesday, May 20, 2009 6:48 AM To: [email protected] Subject: Re: Cache not updated 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 > > >
