Ivy
  1. Ivy
  2. IVY-938

Fixed name snapshots are not updated even if they are marked as changing and the publication date is changed in repo

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-RC1
    • Fix Version/s: None
    • Component/s: Core, Maven Compatibility
    • Labels:

      Description

      Snapshot releases with static name like 1.2.3-SNAPSHOT are not updated into the cache.

      Same problem is with ivy and maven remote repos.

      Here ivy example:

      Remote ivy repo contains in ivy xml:

      status="integration" publication="20081010104634"

      Cache contains (.xml):

      status="integration" publication="20081010095107"

      But ivy_resolve does not update the cache. It prints this with verbose output:

      [ivy-resolve] default: Checking cache for: dependency: org#>module;1.2.3-SNAPSHOT

      {runtime=[runtime]}
      [ivy-resolve] don't use cache for org#>module;1.2.3-SNAPSHOT: changing=true
      [ivy-resolve] local: Checking cache for: dependency: org#>module;1.2.3-SNAPSHOT{runtime=[runtime]}

      [ivy-resolve] local: module revision found in cache: org#>module;1.2.3-SNAPSHOT
      [ivy-resolve] found org#>module;1.2.3-SNAPSHOT in remote_ivy
      ...
      [ivy-resolve] :: downloading artifacts ::
      [ivy-resolve] [NOT REQUIRED] org#>module;1.2.3-SNAPSHOT!module.jar

      1. ivysettings.xml
        6 kB
        Jyri Kytömäki
      2. CacheUpdateTest.zip
        12 kB
        Sergey Shcherbakov
      3. CacheUpdateTest2.zip
        2 kB
        Thomas Laun

        Issue Links

          Activity

          Hide
          Vadim Kopichenko added a comment -
          Show
          Vadim Kopichenko added a comment - See also http://stackoverflow.com/questions/14445268/whats-wrong-with-this-ivy-changingpattern-snapshot-configuration for workarounds for cases with resolvers chain.
          Hide
          William Price added a comment -

          Submitted patch for IVY-1221 likely fixes the use case described in the comment from Dimitris Mouchritsas.

          Show
          William Price added a comment - Submitted patch for IVY-1221 likely fixes the use case described in the comment from Dimitris Mouchritsas.
          Hide
          Lewis John McGibbney added a comment - - edited

          Guys I've been having hellish experiences trying to work the Ivy resolver/ivy.xml/ivysettings.xml problem with Apache Gora.

          I found this thread which seemed to sort it our for you guys, but it seems that a patch has not been produced and attached. It's a pretty trivial thing to fix, once you know the specifics. I don't pull trunk versions of Ivy or else I would attach a patch for this issue.

          http://old.nabble.com/Issue-with-maven-snapshot-pull-strategy-td27182926.html

          Show
          Lewis John McGibbney added a comment - - edited Guys I've been having hellish experiences trying to work the Ivy resolver/ivy.xml/ivysettings.xml problem with Apache Gora. I found this thread which seemed to sort it our for you guys, but it seems that a patch has not been produced and attached. It's a pretty trivial thing to fix, once you know the specifics. I don't pull trunk versions of Ivy or else I would attach a patch for this issue. http://old.nabble.com/Issue-with-maven-snapshot-pull-strategy-td27182926.html
          Hide
          Steve Neal added a comment -

          Hi,

          Is anyone working on this problem? It's causing problems for us too.

          Cheers, Steve.

          Show
          Steve Neal added a comment - Hi, Is anyone working on this problem? It's causing problems for us too. Cheers, Steve.
          Hide
          Davide Cavestro added a comment -

          Hi guys,
          any idea on any workaround that doesn't explicitly delete ivy cache?

          Cheers
          Davide

          Show
          Davide Cavestro added a comment - Hi guys, any idea on any workaround that doesn't explicitly delete ivy cache? Cheers Davide
          Hide
          Dimitris Mouchritsas added a comment -

          Hi all,
          we've been having a similar problem with ivy 2.2.0. We are publishing an artifact with the following target:

          <target name="publish" description="Publish the ear to Nexus" depends="make">
          <ivy:publish organisation="com.company" module="mymodule" revision="1.0-SNAPSHOT"
          srcivypattern="$

          {basedir}

          /ivy.xml" artifactspattern="$

          {dist.dir}

          /$

          {project.artifact.name}

          "
          publishivy="false" conf="master" resolver="my-repo" overwrite="true">
          </ivy:publish>
          </target>

          then in another project we have this dependency in ivy.xml:

          <dependency org="com.company" name="mymodule" rev="1.0-SNAPSHOT" conf="base-prepare->default" changing="true">
          <artifact name="mymodule" type="ear"/>
          </dependency>

          We don't expect the version to change much yet, so I have set the changing="true" to check for newer revisions with the same version. This works on my workstation (Ubuntu 10.04) but on 2 windows pc's with windows xp, ivy fails to download the latest artifact and instead gets it from the local cache.

          Currently as a workaround I have created an ant target to delete the ear file from ivy's local cache directory, but any idea why this occurs?

          Show
          Dimitris Mouchritsas added a comment - Hi all, we've been having a similar problem with ivy 2.2.0. We are publishing an artifact with the following target: <target name="publish" description="Publish the ear to Nexus" depends="make"> <ivy:publish organisation="com.company" module="mymodule" revision="1.0-SNAPSHOT" srcivypattern="$ {basedir} /ivy.xml" artifactspattern="$ {dist.dir} /$ {project.artifact.name} " publishivy="false" conf="master" resolver="my-repo" overwrite="true"> </ivy:publish> </target> then in another project we have this dependency in ivy.xml: <dependency org="com.company" name="mymodule" rev="1.0-SNAPSHOT" conf="base-prepare->default" changing="true"> <artifact name="mymodule" type="ear"/> </dependency> We don't expect the version to change much yet, so I have set the changing="true" to check for newer revisions with the same version. This works on my workstation (Ubuntu 10.04) but on 2 windows pc's with windows xp, ivy fails to download the latest artifact and instead gets it from the local cache. Currently as a workaround I have created an ant target to delete the ear file from ivy's local cache directory, but any idea why this occurs?
          Hide
          Stefan Murawski added a comment -

          It seems to work for the ivy Files. But not for the artifacts themselves (I tried it with 2.1. and a development snapshot (Ivy 2.2.x-local-20100203234032).

          [ivy:retrieve] readybank: Checking cache for: dependency: readybank#TZCommon;jb-0.0.0

          {compile=[*]}

          [ivy:retrieve] don't use cache for readybank#TZCommon;jb-0.0.0: changing=true
          [ivy:retrieve] don't use cache for readybank#TZCommon;jb-0.0.0: checkModified=true
          [ivy:retrieve] tried D:\projects\TZ1/KS.build/jars/TZCommon/jb-0.0.0/ivy-jb-0.0.0.xml
          [ivy:retrieve] jars.local: found md file for readybank#TZCommon;jb-0.0.0
          [ivy:retrieve] => D:\projects\TZ1\KS.build\jars\TZCommon\jb-0.0.0\ivy-jb-0.0.0.xml (jb-0.0.0)
          [ivy:retrieve] default-cache: revision in cache (not updated): readybank#TZCommon;jb-0.0.0

          The timestamp for the jarFiles is different but the size is the same.

          If I enable <caches useOrigin="true" /> it works onyl AFTER I cleared the repository. IF I leave it with a broken file. The broken File will still be downloaded.
          <caches useOrigin="true" /> seems to disable downloading the file, but not skipping the cache if a file is already present.

          Show
          Stefan Murawski added a comment - It seems to work for the ivy Files. But not for the artifacts themselves (I tried it with 2.1. and a development snapshot (Ivy 2.2.x-local-20100203234032). [ivy:retrieve] readybank: Checking cache for: dependency: readybank#TZCommon;jb-0.0.0 {compile=[*]} [ivy:retrieve] don't use cache for readybank#TZCommon;jb-0.0.0: changing=true [ivy:retrieve] don't use cache for readybank#TZCommon;jb-0.0.0: checkModified=true [ivy:retrieve] tried D:\projects\TZ1/KS.build/jars/TZCommon/jb-0.0.0/ivy-jb-0.0.0.xml [ivy:retrieve] jars.local: found md file for readybank#TZCommon;jb-0.0.0 [ivy:retrieve] => D:\projects\TZ1\KS.build\jars\TZCommon\jb-0.0.0\ivy-jb-0.0.0.xml (jb-0.0.0) [ivy:retrieve] default-cache: revision in cache (not updated): readybank#TZCommon;jb-0.0.0 The timestamp for the jarFiles is different but the size is the same. If I enable <caches useOrigin="true" /> it works onyl AFTER I cleared the repository. IF I leave it with a broken file. The broken File will still be downloaded. <caches useOrigin="true" /> seems to disable downloading the file, but not skipping the cache if a file is already present.
          Hide
          Karthik K added a comment -
          This would not retrieve the latest snapshots ( unless we explicitly clear the ivy cache - ~/.ivy2/cache . I tried with the nightly build and the problem persists . Can you help here. The snapshot is public , btw.

          Adding - changing="true" to the dependency makes this work.

          Show
          Karthik K added a comment - This would not retrieve the latest snapshots ( unless we explicitly clear the ivy cache - ~/.ivy2/cache . I tried with the nightly build and the problem persists . Can you help here. The snapshot is public , btw. Adding - changing="true" to the dependency makes this work.
          Hide
          Karthik K added a comment -

          So - we are trying to fetch the latest snapshots from a m2 repository. The ivy settings file is given herewith.

          <ivysettings>
             <property name="repo.maven.org" value="http://repo1.maven.org/maven2/" override="false"/>
            <property name="snapshot.apache.org" value="https://repository.apache.org/content/repositories/snapshots/" override="false"/>
            <property name="maven2.pattern" value="[organisation]/[module]/[revision]/[module]-[revision]"/>
            <property name="maven2.pattern.ext" value="${maven2.pattern}.[ext]"/>
            
            <property name="maven2.pattern" value="[organisation]/[module]/[revision]/[module]-[revision]"/>
            <property name="maven2.pattern.ext" value="${maven2.pattern}.[ext]"/>
            
           <settings defaultResolver="default"/>
            <resolvers>
              <!--ibiblio resolvers-->
              <ibiblio name="maven2" root="${repo.maven.org}" m2compatible="true"/>
              <ibiblio name="apache-snapshot" root="${snapshot.apache.org}" m2compatible="true"
                  checkmodified="true" changingPattern=".*SNAPSHOT"/>
           
              <chain name="default" dual="true">
                <resolver ref="maven2"/>
                <resolver ref="apache-snapshot" />
              </chain>
            </resolvers>
          
          </ivysettings>
          

          This would not retrieve the latest snapshots ( unless we explicitly clear the ivy cache - ~/.ivy2/cache . I tried with the nightly build and the problem persists . Can you help here. The snapshot is public , btw.

          Show
          Karthik K added a comment - So - we are trying to fetch the latest snapshots from a m2 repository. The ivy settings file is given herewith. <ivysettings> <property name= "repo.maven.org" value= "http: //repo1.maven.org/maven2/" override= " false " /> <property name= "snapshot.apache.org" value= "https: //repository.apache.org/content/repositories/snapshots/" override= " false " /> <property name= "maven2.pattern" value= "[organisation]/[module]/[revision]/[module]-[revision]" /> <property name= "maven2.pattern.ext" value= "${maven2.pattern}.[ext]" /> <property name= "maven2.pattern" value= "[organisation]/[module]/[revision]/[module]-[revision]" /> <property name= "maven2.pattern.ext" value= "${maven2.pattern}.[ext]" /> <settings defaultResolver= " default " /> <resolvers> <!--ibiblio resolvers--> <ibiblio name= "maven2" root= "${repo.maven.org}" m2compatible= " true " /> <ibiblio name= "apache-snapshot" root= "${snapshot.apache.org}" m2compatible= " true " checkmodified= " true " changingPattern= ".*SNAPSHOT" /> <chain name= " default " dual= " true " > <resolver ref= "maven2" /> <resolver ref= "apache-snapshot" /> </chain> </resolvers> </ivysettings> This would not retrieve the latest snapshots ( unless we explicitly clear the ivy cache - ~/.ivy2/cache . I tried with the nightly build and the problem persists . Can you help here. The snapshot is public , btw.
          Hide
          Maarten Coene added a comment -

          You can download latest trunk build here:
          http://hudson.zones.apache.org/hudson/view/Ant/job/Ivy/

          Maarten

          Show
          Maarten Coene added a comment - You can download latest trunk build here: http://hudson.zones.apache.org/hudson/view/Ant/job/Ivy/ Maarten
          Hide
          Karthik K added a comment -

          Could you try trunk version and confirm that the problem has been solved?

          Is there a repository where the trunk build is maintained. This is really blocking us from integrating with some m2 snapshot repositories.

          Show
          Karthik K added a comment - Could you try trunk version and confirm that the problem has been solved? Is there a repository where the trunk build is maintained. This is really blocking us from integrating with some m2 snapshot repositories.
          Hide
          Maarten Coene added a comment -

          Could you try trunk version and confirm that the problem has been solved?

          thanks,
          Maarten

          Show
          Maarten Coene added a comment - Could you try trunk version and confirm that the problem has been solved? thanks, Maarten
          Hide
          Peter Niederwieser added a comment -

          Same problem here, causes lots of problems for us.

          Show
          Peter Niederwieser added a comment - Same problem here, causes lots of problems for us.
          Hide
          Matt Benson added a comment -

          My understanding is that the code for 2.1.0 was more or less frozen by the time this fix was added to trunk. Next time... :| Personally I've been using 2.1.0 in Eclipse with IvyDE, but I use a trunk build with Ant to resolve updated snapshot artifacts.

          Show
          Matt Benson added a comment - My understanding is that the code for 2.1.0 was more or less frozen by the time this fix was added to trunk. Next time... :| Personally I've been using 2.1.0 in Eclipse with IvyDE, but I use a trunk build with Ant to resolve updated snapshot artifacts.
          Hide
          Stefan Murawski added a comment -

          Is this Bug fixed in 2.1?
          For my Project this Bug is blocking the use of ivy, and I really want to use it

          Show
          Stefan Murawski added a comment - Is this Bug fixed in 2.1? For my Project this Bug is blocking the use of ivy, and I really want to use it
          Hide
          Carlton Brown added a comment - - edited

          I have not been able to get this working with the trunk revision. In fact I found that the behavior is a race condition when the latest-time strategy is used on both the subresolvers in the chain.

          Question - When Ivy is iterating a chain, and it finds 2 instances of the same module/revision in different subresolvers, what is the expected behavior? Can Ivy use latest-time to decide which is latest? Or is it incapable of evaluating these as distinct revisions?

          Show
          Carlton Brown added a comment - - edited I have not been able to get this working with the trunk revision. In fact I found that the behavior is a race condition when the latest-time strategy is used on both the subresolvers in the chain. Question - When Ivy is iterating a chain, and it finds 2 instances of the same module/revision in different subresolvers, what is the expected behavior? Can Ivy use latest-time to decide which is latest? Or is it incapable of evaluating these as distinct revisions?
          Hide
          Paul Andrews added a comment -

          Works for me too! I echo Matt Benson's request.

          Show
          Paul Andrews added a comment - Works for me too! I echo Matt Benson's request.
          Hide
          Matt Benson added a comment -

          I'd love to see this in 2.1.0 final!

          Show
          Matt Benson added a comment - I'd love to see this in 2.1.0 final!
          Hide
          Thomas Laun added a comment -

          Hello Maarten,

          I tried your fix. It works both for my test project and my real world project. Now the artifact is downloaded from the repository when the timestamp in the repository is newer than in the cache. When the timestamps are equal, the artifact is correctly taken from the cache.

          Thanks!

          Show
          Thomas Laun added a comment - Hello Maarten, I tried your fix. It works both for my test project and my real world project. Now the artifact is downloaded from the repository when the timestamp in the repository is newer than in the cache. When the timestamps are equal, the artifact is correctly taken from the cache. Thanks!
          Hide
          Maarten Coene added a comment -

          I've committed a fix into SVN trunk that could solve some of the problems.
          Could you give it a try and post your feedback?

          thanks,
          Maarten

          Show
          Maarten Coene added a comment - I've committed a fix into SVN trunk that could solve some of the problems. Could you give it a try and post your feedback? thanks, Maarten
          Hide
          Maarten Coene added a comment -

          Ivy doesn't search for an ivy file because you didn't define an ivy-pattern in your 'hudson_sper' url resolver

          Try something like:

          <url name="hudson_sper" changingMatcher="regexp" changingPattern=".*SNAPSHOT.*" checkmodified="true">
          	<ivy pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/ivy.xml" />
          	<artifact pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/[artifact].[ext]"/>
          </url>
          

          Maarten

          Show
          Maarten Coene added a comment - Ivy doesn't search for an ivy file because you didn't define an ivy-pattern in your 'hudson_sper' url resolver Try something like: <url name="hudson_sper" changingMatcher="regexp" changingPattern=".*SNAPSHOT.*" checkmodified="true"> <ivy pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/ivy.xml" /> <artifact pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/[artifact].[ext]"/> </url> Maarten
          Hide
          Paul Andrews added a comment - - edited

          The file is being served by hudson directly. The configuration I use is as follows:

          <ivysettings>
          	<settings defaultResolver="chained"/>
          	<latest-strategies>
          		<latest-time name="time"/>
          	</latest-strategies>
          	<resolvers>
          		<chain name="chained" returnFirst="true">
          			<!-- For getting stuff from the Maven 2 repo on gendev-lnx -->
          			<ibiblio
          				name="internal"
          				m2compatible="true"
          				usepoms="false"
          				root="http://gendev-lnx:9090/artifactory/repo"/>
          			<!-- For getting stuff from the hudson repo on gendev-lnx -->
          			<url name="hudson_sper" changingMatcher="regexp" changingPattern=".*SNAPSHOT.*" checkmodified="true">
          				<artifact pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/[artifact].[ext]"/>
          			</url>
          		</chain>
          	</resolvers>
          </ivysettings>
          

          The snapshot artifact is not in the "internal" repository, it is in "hudson_sper". I have traced the TCP traffic to both repositories and Ivy only issues one request: an HTTP HEAD request for the artifact itself. At no time does it attempt to retrieve an ivy file. The server returns a modification date later than the modification date of any copy of the artifact on my local machine - either in the ivy cache or in the location that the artifact is copied to by the resolver.

          I don't see much point 'publishing' an ivy file to hudson_sper, since Ivy makes no attempt to access one anyway.

          BTW I have tried several variations of the above settings file (for example removing the <latest-strategies> stanza, not specifying the matcher etc. The results are the same.

          Show
          Paul Andrews added a comment - - edited The file is being served by hudson directly. The configuration I use is as follows: <ivysettings> <settings defaultResolver="chained"/> <latest-strategies> <latest-time name="time"/> </latest-strategies> <resolvers> <chain name="chained" returnFirst="true"> <!-- For getting stuff from the Maven 2 repo on gendev-lnx --> <ibiblio name="internal" m2compatible="true" usepoms="false" root="http://gendev-lnx:9090/artifactory/repo"/> <!-- For getting stuff from the hudson repo on gendev-lnx --> <url name="hudson_sper" changingMatcher="regexp" changingPattern=".*SNAPSHOT.*" checkmodified="true"> <artifact pattern="http://gendev-lnx:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/[artifact].[ext]"/> </url> </chain> </resolvers> </ivysettings> The snapshot artifact is not in the "internal" repository, it is in "hudson_sper". I have traced the TCP traffic to both repositories and Ivy only issues one request: an HTTP HEAD request for the artifact itself. At no time does it attempt to retrieve an ivy file. The server returns a modification date later than the modification date of any copy of the artifact on my local machine - either in the ivy cache or in the location that the artifact is copied to by the resolver. I don't see much point 'publishing' an ivy file to hudson_sper, since Ivy makes no attempt to access one anyway. BTW I have tried several variations of the above settings file (for example removing the <latest-strategies> stanza, not specifying the matcher etc. The results are the same.
          Hide
          Maarten Coene added a comment -

          Yes I know it might seem a little strange, but with an ivy file, the outdated artifacts will get deleted from your cache somewhere earlier during the resolve process. So the archiveFile.exists() will return false in that case.
          Probably, the bug in Ivy is that without an ivy file, this artifact doesn't get deleted and your tracing shows that in that case the artifact will never get downloaded. However, this is just a guess and you could help to give me a better understanding of the problem here by checking if it works when you have an Ivy file, so I know I'm looking into the right direction for solving this problem.

          Maarten

          Show
          Maarten Coene added a comment - Yes I know it might seem a little strange, but with an ivy file, the outdated artifacts will get deleted from your cache somewhere earlier during the resolve process. So the archiveFile.exists() will return false in that case. Probably, the bug in Ivy is that without an ivy file, this artifact doesn't get deleted and your tracing shows that in that case the artifact will never get downloaded. However, this is just a guess and you could help to give me a better understanding of the problem here by checking if it works when you have an Ivy file, so I know I'm looking into the right direction for solving this problem. Maarten
          Hide
          Paul Andrews added a comment -

          The artifact is generated by another project and having traced through the code I don't see how it would help to generate an Ivy file (see my comment of 22/Jul/09).

          Show
          Paul Andrews added a comment - The artifact is generated by another project and having traced through the code I don't see how it would help to generate an Ivy file (see my comment of 22/Jul/09).
          Hide
          Maarten Coene added a comment -

          Paul, a possible workaround, could you modify your Hudson build so it also creates an Ivy file?

          Show
          Maarten Coene added a comment - Paul, a possible workaround, could you modify your Hudson build so it also creates an Ivy file?
          Hide
          Paul Andrews added a comment -

          I traced through the code and I don't see any way that this can possibly work. Basically DefaultRepositoryCacheManager.download() always performs the following check:

          if (archiveFile.exists() && !options.isForce())

          { ... }

          options always has 'force' set to false for the actual artifact, so as long as the file exists in the cache, it will never be downloaded.

          Show
          Paul Andrews added a comment - I traced through the code and I don't see any way that this can possibly work. Basically DefaultRepositoryCacheManager.download() always performs the following check: if (archiveFile.exists() && !options.isForce()) { ... } options always has 'force' set to false for the actual artifact, so as long as the file exists in the cache, it will never be downloaded.
          Hide
          Paul Andrews added a comment - - edited

          Same problem here (with 2.1.0-RC1). I have changing="true" on the dependency and changingPattern=".SNAPSHOT." checkmodified="true" on (in this case) a URL resolver called hudson_sper. Running ant -v I see the following:

          [ivy:resolve] == resolving dependencies com.ftid.sper#sper_svc_ejb;working@A55584->com.ftid.sper#sperDbServer;SNAPSHOT [dist->default]
          [ivy:resolve] chained: Checking cache for: dependency: com.ftid.sper#sperDbServer;SNAPSHOT

          {dist=[default]}

          [ivy:resolve] don't use cache for com.ftid.sper#sperDbServer;SNAPSHOT: changing=true
          [ivy:resolve] don't use cache for com.ftid.sper#sperDbServer;SNAPSHOT: checkModified=true
          [ivy:resolve] tried http://localhost:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/sperDbServer.jar
          [ivy:resolve] hudson_sper: no ivy file found for com.ftid.sper#sperDbServer;SNAPSHOT: using default data
          [ivy:resolve] found com.ftid.sper#sperDbServer;SNAPSHOT in hudson_sper

          And later:

          [ivy:resolve] [NOT REQUIRED] com.ftid.sper#sperDbServer;SNAPSHOT!sperDbServer.jar

          Note that there is no Ivy file associated with the artifact - it is just an artifact created by a Hudson build.

          I traced the requests being sent to the server: Ivy is sending a HEAD request and getting back a later modification date than the one that is in the cache, but it never issues the GET.

          Show
          Paul Andrews added a comment - - edited Same problem here (with 2.1.0-RC1). I have changing="true" on the dependency and changingPattern=". SNAPSHOT. " checkmodified="true" on (in this case) a URL resolver called hudson_sper. Running ant -v I see the following: [ivy:resolve] == resolving dependencies com.ftid.sper#sper_svc_ejb;working@A55584->com.ftid.sper#sperDbServer;SNAPSHOT [dist->default] [ivy:resolve] chained: Checking cache for: dependency: com.ftid.sper#sperDbServer;SNAPSHOT {dist=[default]} [ivy:resolve] don't use cache for com.ftid.sper#sperDbServer;SNAPSHOT: changing=true [ivy:resolve] don't use cache for com.ftid.sper#sperDbServer;SNAPSHOT: checkModified=true [ivy:resolve] tried http://localhost:9090/hudson/job/SPER/lastSuccessfulBuild/artifact/sper/java/dist/sperDbServer.jar [ivy:resolve] hudson_sper: no ivy file found for com.ftid.sper#sperDbServer;SNAPSHOT: using default data [ivy:resolve] found com.ftid.sper#sperDbServer;SNAPSHOT in hudson_sper And later: [ivy:resolve] [NOT REQUIRED] com.ftid.sper#sperDbServer;SNAPSHOT!sperDbServer.jar Note that there is no Ivy file associated with the artifact - it is just an artifact created by a Hudson build. I traced the requests being sent to the server: Ivy is sending a HEAD request and getting back a later modification date than the one that is in the cache, but it never issues the GET.
          Hide
          Thomas Laun added a comment -

          I also ran into the problem that the cache is not updated. To reproduce the error, I have created a very simple application (see CacheUpdateTest2.zip). It contains of two projects name Application and Library. When Library is build, it will publish it's artifacts to a local repository. Application will use the local cache to retrieve it's dependency to Library.

          To reproduce the error, do the following:

          • Compile Library
          • Compile Application
          • Wait some time so that the time stamps on the file will differ.
          • Compile Library again. This will update the artifacts in the repository.
          • Compile Application again. In theory, the cache should be updated with the new version of library. But when you compare the time stamps, you will see that the cache and Application still use the old version.

          The only workaround I found so far was to delete the cache. Everything else I tried (setting changinging="true", defining a changing pattern, etc.) did not work out.

          Show
          Thomas Laun added a comment - I also ran into the problem that the cache is not updated. To reproduce the error, I have created a very simple application (see CacheUpdateTest2.zip). It contains of two projects name Application and Library . When Library is build, it will publish it's artifacts to a local repository. Application will use the local cache to retrieve it's dependency to Library . To reproduce the error, do the following: Compile Library Compile Application Wait some time so that the time stamps on the file will differ. Compile Library again. This will update the artifacts in the repository. Compile Application again. In theory, the cache should be updated with the new version of library. But when you compare the time stamps, you will see that the cache and Application still use the old version. The only workaround I found so far was to delete the cache. Everything else I tried (setting changinging="true", defining a changing pattern, etc.) did not work out.
          Hide
          Sergey Shcherbakov added a comment - - edited

          The issue remains in the 2.1.0-RC1 release.
          The snapshot artifact doesn't get updated in the ivy cache.
          Attached are three very simple projects that illustrate the issue.
          Projects depend on each other in the following way: gamma -> beta -> alfa.
          Alfa is a maven project that publishes a snapshot artifact into the maven repository.
          Beta and Gamma are Ant+Ivy projects.
          After you have compiled and published artifacts of these three projects once, change Alfa and Beta projects (for example, their output), rebublish them and then build Gamma.
          As you can see, the snapshot artifact from the Alfa project gets updated in cache properly, but the Beta artifact not.

          Show
          Sergey Shcherbakov added a comment - - edited The issue remains in the 2.1.0-RC1 release. The snapshot artifact doesn't get updated in the ivy cache. Attached are three very simple projects that illustrate the issue. Projects depend on each other in the following way: gamma -> beta -> alfa. Alfa is a maven project that publishes a snapshot artifact into the maven repository. Beta and Gamma are Ant+Ivy projects. After you have compiled and published artifacts of these three projects once, change Alfa and Beta projects (for example, their output), rebublish them and then build Gamma. As you can see, the snapshot artifact from the Alfa project gets updated in cache properly, but the Beta artifact not.
          Hide
          Sergey Shcherbakov added a comment -

          Projects illustrating the issue

          Show
          Sergey Shcherbakov added a comment - Projects illustrating the issue
          Hide
          Jyri Kytömäki added a comment -

          Thank you. That helped. I think I earlier even tried to mark the module in ivy.xml as changing, but it didn't help.
          It would be nice to be able set that with defaultChangingPattern attribute in settings element.

          Show
          Jyri Kytömäki added a comment - Thank you. That helped. I think I earlier even tried to mark the module in ivy.xml as changing, but it didn't help. It would be nice to be able set that with defaultChangingPattern attribute in settings element.
          Hide
          Maarten Coene added a comment -

          I think the problem is that you did only define the chaning pattern on your "internal_modules" and "external_modules" resolver.
          As far as I could see from the codebase, the chain resolver doesn't pass this attribute to it's child resolvers, so they don't know anything about this changing pattern on their parent resolver.

          Could you try adding the changing pattern to all your resolvers where approprioate?

          Show
          Maarten Coene added a comment - I think the problem is that you did only define the chaning pattern on your "internal_modules" and "external_modules" resolver. As far as I could see from the codebase, the chain resolver doesn't pass this attribute to it's child resolvers, so they don't know anything about this changing pattern on their parent resolver. Could you try adding the changing pattern to all your resolvers where approprioate?
          Hide
          Jyri Kytömäki added a comment -

          Ivysettings attached.
          Note: We are using separate caches for remote and local repos, because otherwise locally built SNAPSHOT version wouln't be used after one is retrieved from remote repo unless cache is cleared.

          Show
          Jyri Kytömäki added a comment - Ivysettings attached. Note: We are using separate caches for remote and local repos, because otherwise locally built SNAPSHOT version wouln't be used after one is retrieved from remote repo unless cache is cleared.
          Hide
          Maarten Coene added a comment -

          Could you post your settings here?

          Show
          Maarten Coene added a comment - Could you post your settings here?

            People

            • Assignee:
              Unassigned
              Reporter:
              Jyri Kytömäki
            • Votes:
              18 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:

                Development