I actually do implement a "dual publish". I publish a unique snapshot that includes an svn rev number in the version number, and then a generic snapshot that does not. I publish the same artifact twice. For example, myartifact-1.0.0_5353-SNAPSHOT and myartifact-1.0.0-SNAPSHOT. If you want the latest, depend upon the latter (sans the cache issues that I am having).
The latter is always the "latest" build and not a "specific" build. That is by design. I want to be able to perform an integration build against the most recent commits (every commit if possible) and break early if there is a compilation problem. Jenkins will report the latest commit that broke the build. I don't need a unique version number to figure that part out. Then for functional testing, we use the uniquely versioned artifacts for obvious reasons. You can't test a moving target. What I wish to avoid is having Ivy evaluate version numbers and determine which is the latest version for integration purposes. Developers often like to get their freak on when it comes to version numbering and eventually Ivy is not going to like it. The only way to determine the "latest" version of something with certainty is in the time domain. Latest means "most recent in time" not alphabetically last, or numerically larger, or it matches my funky regex, or anything else. It is nice that Ivy can attempt to determine the latest version, and perhaps it does so very well, but eventually actual lives will be in the balance and blaming a developer for creating a breaking version number will not be an option for me. I have no choice but to use clock time to determine what the "latest" version of something is. So latest.integration is a non-starter for me. Please do not take that as a lecture. I am just explaining my constraints in painful detail. I have been over the pages that you referenced many times. And again, this response is like so many other Ivy responses. It points to a page, which points at configuration documentation, which fails to provide a complete example of the desired behavior. Within the docs, it tells me what you said, that I should really use unique version numbers. And above I have explained in great detail that I do, and why I cannot allow Ivy to interpret those numbers to determine the latest version. I can only use actual time. Nothing less. In my other response, I displayed a configuration that correctly obtains the latest snapshot from Nexus every time until a local publish to the internal repo happens. Then Ivy delivers only the cached version from the external repo forever (not even the local publish). It will no longer pick up new snapshots from the Nexus repo, and will not deliver the locally published artifact. When debugging Ivy, Ivy would find the artifact in my internal repository and proceed to deliver the stale artifact from the cache thinking that it is a cached version of the artifact from the internal repository, but it is actually a cached version of the Nexus artifact. I am fairly certain that Ivy is broken. This is definitely a bug. Either that, or Ivy assumes that an artifact can only come from one place, and once it comes from that place, it can come from no other place, ever. I don't believe that was the intent of the designers. One last possibility is that I have conjured up a very unfortunate combination of configuration attributes. I hope that this is the case. I appreciate the pointers to the docs. I am sorry but they fall short otherwise I would have had this working by now. I need a working config, not more Ivy docs. I have been reading those for a year now. Yes, it is possible that I am missing something. I hope that I am. But all indications are that Ivy is broken. Failing a working config, I will move the discussion to the developers list. If Ivy would not substitute the cached version of the incorrect artifact for the found artifact at the last moment, everything would work properly. L.K. -----Original Message----- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: Sunday, March 22, 2015 2:30 PM To: ivy-user@ant.apache.org Subject: Re: cache busting and integration question Please have a look at the paragraphs "Dealing with integration versions" in http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html: The "typical" developer workflow using SNAPSHOT builds of a release, has become popular because it is the standard in Maven. A disadvantage of using SNAPSHOT-builds, is however that you can never be sure which build you have finally gotten after a dependency has been resolved. A more controlled way of dealing with your dependencies, is to create a new version for every build that is made, and to resolve for your local builds using the revision 'latest.integration' for "home-made" artifacts. Ivy supports both methods of resolving dependencies. The URL http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html describes how you can implement the "SNAPSHOT" approach using Ivy. Regards, Marc 2015-03-20 23:12 GMT+01:00 Loren Kratzke <lkrat...@blueorigin.com>: > I am encountering challenges with the Ivy cache and also with setting > up what I would consider to be a typical (if not classic) developer workflow. > Here is the desired workflow: > > I have a Nexus repository (releases and snapshots) plus a local file > system repository used for local development. I have Project which > depends upon Library. I wish to modify Library, publish locally, and > then pull it into the local build of Project. > > And for my Jenkins "continuous" integration server, if the copy of > Library-1.0.0-SNAPSHOT in Nexus is newer than what is in the cache on > the build machine, then I would like Ivy to grab the newer version > (just like Maven does). > > ISSUE #1 > > Assuming I start with an empty cache and empty internal repo on my > local dev machine, I build Project and it pulls Library from Nexus. Perfect. > Works great. But then if I publish Library locally and build Project > again, I will get the cached version of Library that came from Nexus. > No matter what I do, I will always get the cached copy. This happens > even though my chain resolver specifies my internal repo before the Nexus > repo. > > If I blow away the cache, then I get my locally published build, but > only if I blow away the cache. Otherwise I get stale stuff. Issue #2 > below is all about stale stuff. > > I debugged Ivy (for hours upon hours) and during the resolve, it > checks my internal repo, finds the fresh artifact (yay!) and the next > thing it does is checks its cache, finds a module descriptor that > points at Nexus, and proceeds to pull in the wrong artifact into Project. > > The behavior is either a bug, or implies that Ivy assumes that an > artifact can only come from one place, and if it came from there once, > it will come from there forever, and will never change. Again, Ivy > finds the artifact in local repo, stops searching, then ends up > delivering the cached artifact that came from Nexus sometime earlier. > > ISSUE #2 > > I have been working on this problem for quite some time and I thought > I had it fixed, but I don't. That is, my integration server needs the > latest snapshot build of Library-1.0.0-SNAPSHOT. But what I get is the > cached version from the Ivy cache. An SVN commit happens, triggers a > build of Library, Library get published, triggers a build of Project, > and a stale build of Library is delivered to Project from the cache > (which breaks Project build). > > SUMMARY > > Ivy will resolve and cache deps, but once a dep is in the cache, > that's what I get forever until I blow away the cache. I see this > question asked quite often regarding obtaining latest integration > versions, and I see that Ivy claims to support the local development > workflow, but I have yet to see a working example of either of these. > Surely some of you have solved these issues. > > Is there any place anywhere in the world that has an example of > development workflow configuration and/or integration configuration? > Can anybody provide an example? So far I have not found anything, and > advice on the net seems to be general suggestions like "try this, try > that" and nobody really has the configuration solution. Is Ivy capable > of these behaviors or do I need to hand roll a dependency management > solution. Maven is too strict for these projects (C++ code). Ivy is > good if I can just obtain these fundamental behaviors. > > Note that I have not provided any configs in this message that > demonstrate the issues I am having but definitely can upon request. > > Thanks in advance, > > L.K. > >
