You’re right, metadatas are not up-to-date, no idea where it comes from for now, investigating.
Until we find out, could you just remove the gatling directory from your Jenkins local repo?
I’m using the Cloudbess jenkins so I don’t know how to do it. The sole solution I see is to use a per job Maven repository
My2cents: snapshot metadatas are not computed on publish, but are batched computed once a day. Current metadata pretends that last update is 20140412131623, ie yesterday.
Yes, I sought it was computed as part of the deploy phase. I’m running the job with the prive repository option so it should download every artifacts. Waiting for the job to complete.
Jeff
I thought so to.
We’ll open an issue on Sonatype to find out.
https://docs.sonatype.com/display/SPRTNXOSS/Nexus+FAQ#NexusFAQ-Q.The"latest"and"release"tagsinmaven-metadata.xmlarenotbeingupdatedafterdeployingartifacts
Actually, this is not a bug but expected behavior.
If -U doesn’t force update, that’s probably a Jenkins/Cloudbees issue.
Could you try setting updatePolicy to always in your pom, please?
always
I need to focus on my tests now as I more than late for friday !!!
Anyway, I don’t think this will fix the issue as the metadata.xml is not uptodate.
Jeff
Read the FAQ: maven isn’t supposed to use them the way you think.
Maven should use repository metadatas to determine if snapshot is supposed to be updated.
shouldn’t
Maybe a problem with the Maven version available at Cloudbees ?
Jeff
Maybe.
Or maybe that Cloudbees proxifies maven central into it’s own maven repository, and there’s a cache expiration delay that’s too high for snapshots.
If you’re still stuck by next week, maybe I could temporarily host a timestamped version on a private repository.
No, I’m ok now with the private Maven repo per job.
Jeff
Glad to hear!