That is excellent insight. Thank you for that. The things you found encourage 
me to fix the issues that I am seeing (or patch them).

We are publishing and consuming C++ artifacts using Ivy/Nexus. We also have a 
Maven side of the house but they use a different Nexus repo dedicated to pure 
Java artifacts. So I have not seen any Ivy/Maven cross pollination issues. 

Based upon your comments however I will inspect the metadata files and check 
into the timestamps. Hopefully the parts that we are using on the Ivy side are 
ok.

I agree about the cache implementation being tied to the resolvers. I 
considered writing a new resolver but the resolution and download of the 
artifacts works just fine. It is higher up where the problems begin, like the 
chain resolver and cache as you mentioned. 

The one thing that is working for us right now is torching the ivy cache before 
every build. That does not imply very nice things about the ivy cache 
functionality. It is more of a liability than as asset to us. 

I will try to fix this. Ivy is a good technology. It just needs some tough love.

L.K.

-----Original Message-----
From: Josh Suereth [mailto:joshua.suer...@gmail.com] 
Sent: 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 of this is 
that the chain resolver wasn't ever looking for -SNAPSHOTs when we wanted it to.

We actually did the following, recently ->

1. A new chain resolver implementation which forces a date check against
the remote repository.   It turns out this exposed issues in publication
date not being a universal thing.  E.g. pom.xml files weren't reporting 
legitimate publication dates, leading to any attempt to pull "latest" for a 
snapshot being wrong.

2.  We created a new implementation of DependencyResolver which actually
uses aether.   This had two side effects:

2a. We avoid parent pom issues which still sneak in when using -SNAPSHOT 
parents or weird profiles in POM's (why hadoop, why!!!)

2b. We always correctly update maven-metadata.xml and maven-metadata-local.xml. 
 this means we'll have a somewhat legitimate publication date to do loose 
comparisons on (not exact but good enough).

Both are still in experimental stage, but both now pass our previously failing 
test cases around -SNAPSHOT updates, when used together.

What does this mean for ivy?

1. Ivy should probably support maven-metadata(-local).xml directly in its maven 
code.
2. Ivy chain resolver / ivy cache may need tweaks for dynamic revisions to make 
sure, even if the version number is the same, that remote repositories (or just 
metadata.xml) is checked.

This adventure lead me to believe that the ivy cache api itself may need a
3.0 overhaul, and the maven code may need to be further separated from "core" 
usage.  While the loss of reuse would be sad, I think the reality is maven just 
doesn't work the way ivy was designed.
On Mar 23, 2015 12:33 PM, "Loren Kratzke" <lkrat...@blueorigin.com> wrote:

> I am not getting the results that you describe. I am testing with a 
> simple project that publishes a text file with the current date and 
> time so it is very easy to see when I get a fresh or stale artifact. 
> When I run using the configuration below, I get the following results 
> when I publish my dependency and then consume it in the downstream project:
>
> [pub nexus] [get nexus] good
> [pub nexus] [get nexus] good
> [pub local] [get cached nexus artifact] bad [pub nexus] [get cached 
> nexus artfiact] bad
>
> So as the first two tests indicate, I can get the latest snapshot from 
> Nexus. That will work well for the integration server if we leave the 
> local repo out.
>
> But as the 3rd and 4th tests indicate, if  I do a local publish then 
> everything goes to hell. I do not get my local artifact, I get the 
> cached artifact. And if I publish to Nexus again, I still get the cached 
> artifact.
> In fact I get the cached artifact forever after a local publish no 
> matter what gets published or where.
>
> That can't be desired behavior. There has to be a bug here somewhere, 
> but I would be most happy with a work around. This behavior was 
> witnessed when I debugged. It would find a local artifact, check its 
> cache to find an ivy file that points at Nexus, and ultimately return 
> a stale Nexus artifact from the cache.
>
> My setup is very simple - One Nexus repository and one local repository.
> Nothing fancy here. I have tried every combination of "checkmodified", 
> "changingPattern", and "force" that the configuration can tolerate 
> without it quacking a fur ball back at me but I cannot seem to get the 
> desired behavior. Please find the err in my ways and show me where I 
> have wandered off the ranch.
>
> I thought I had this working - once - and I changed something and 
> can't seem to get it back. I thought I had it working as you described 
> where it would pick up the snapshots, then it would pick up my local 
> artifact, and it would always deliver the local artifact if present 
> until the local cache was torched. That behavior is ok with me if I could get 
> it back.
>
> Here is my settings.xml
>
> <ivysettings>
>     <caches defaultCacheDir="${user.home}/.ivy2/cache"/>
>     <settings defaultResolver="chain"/>
>     <credentials host="nexus.mycompany.com" realm="Sonatype Nexus 
> Repository Manager" username="name" passwd="pass"/>
>
>     <property name="m2pattern"
> value="[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
>     <property name="internal.repo.dir" value="${user.home}/.ivy2/m2"/>
>     <property name="mycompany.repo.url" value="
> http://nexus.mycompany.com:8081/nexus/content/repositories"/>
>
>     <resolvers>
>         <filesystem name="internal" force="true" checkmodified="true"
> changingPattern=".*">
>             <ivy
> pattern="${internal.repo.dir}/[module]/ivy-[revision].xml" />
>             <artifact pattern="${internal.repo.dir}/${m2pattern}" />
>         </filesystem>
>
>         <url name="nexus-snapshots-noplatform" m2compatible="true"
> checkmodified="true" changingPattern=".*">
>             <artifact
> pattern="${mycompany.repo.url}/snapshots/${m2pattern}" />
>         </url>
>
>         <chain name="chain" checkmodified="true">
>             <resolver ref="internal"/>
>             <resolver ref="nexus-snapshots-noplatform"/>
>         </chain>
>     </resolvers>
>
> </ivysettings>
>
> L.K.

Reply via email to