Ivy works perfectly with a single repository or even a chain of repositories provided that a dependency does not try to come from two places.
Ivy records where an artifact comes from but does not take into account that it may come from a different place next time. When Ivy finds a candidate artifact in a repository somewhere, it checks the .ivy cache for that artifact, finds an artifact in the cache (that happens to originate from somewhere else), doesn't check or realize that it is from somewhere else, checks the module descriptor against the origin and determines that the stale artifact is up to date with its stale origin, and then assumes that the stale artifact is the same as the found artifact. It does not compare the locations and invalidate the cached artifact. Rather, it delivers the stale artifact that originated from a different location than the found artifact. THAT is a bug. It has to be a bug. There is no way that this is not a bug. Got that out of my system. Whew! That said, using a local repo and "force" tends to overcome this behavior (in theory, and in my testing, and only sometimes). Results of whether you get a fresh artifact range from "never", to "the second time and after that", to "always but only ever from one place" depending upon the configuration. I think this is fixable or at least patchable though. For example, when I find an artifact in a file system repository, WHY would I want to check my cache for that artifact? The artifact is already right-freaking-there on my file system. It is "here". It can't be any closer without already being delivered to my project. Only trouble can come from querying the cache when you have the desired artifact in your hand already. And to then proceed to find and return an older artifact from the cache that came from a different repo is just not cool at all. **Should not check the cache for an artifact that was found in a file system repository. **Should not assume that cached artifact came from same repo as found artifact. **Should at least check the date to know that the cached artifact about to be returned is older than the found artifact. Perhaps using a different cache directory for each repository would help on that last point, but there is nothing that makes me think that Ivy would not search all of its caches and produce a similar outcome of providing a stale artifact fetched at an earlier time and from a different repository. I may be a bit jaded at this point. But I have many hours in on this so can vent a little. Part of the problem is that Ivy developers somewhere along the line separated the module descriptor from the module that it describes, and both of those from the repository which provided each, recording the origin location of the artifact in the cached module descriptor instead of using independent cache directories per repo and using metadata files, and then not leveraging that origin information to know that it has totally not found a cached version of a found artifact. That's 4 strikes that all add up to a very broken and at times quite silly cache mechanism. I am banking on some of this being a bug and some of it being by design, but mostly bug. When I go back into Ivy source code, I am going to see if I can disable the cache checking when an artifact is found using 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 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 an environment with a local and a central repo, but we don't use the checkmodified attribute. If it would work, it is indeed a good idea to setup such a resolver chain with SNAPSHOT builds for the developers. In our case (without checkmodified=true) the detection of changes in both local and central repo works correctly for us. Now, I can only search with you in the docs hoping to find a missing setting (if it's not an actual bug as you suggested). I suppose that the publication date of the ivy.xml that you published in your local repo is more recent than the one in your cache ? Did you also try setting the "changing" attribute directly in the dependency itself (allthough I expect the behaviour will be similar). Could you try a setup where you only publish and resolve from the local repo (so not chained with your Nexus) ? You also wrote that latest.integration is a non-starter for you ? So could you describe how you specify your dependencies ? If you specify an exact revision in your dependency (like rev="1.0.0-SNAPSHOT), then maybe you could also try to set the attribute "alwaysCheckExactRevision" in the settings of your resolver. Regards, Marc 2015-03-23 17:33 GMT+01:00 Loren Kratzke <lkrat...@blueorigin.com>: > I am not getting the results that you describe...
