Stephen: It's good to keep in mind what's meant by "newer." I'm assuming you haven't modified Ivy's latest strategy. The default latest strategy is the built-in "latest-revision", so by default Ivy looks only at the revision, not the timestamp. There is a built-in latest strategy called "latest-time", but it's not used by default.
So the case you describe here is a tie if both local and shared have the same -SNAPSHOT: "And I have a new SNAPSHOT in local-m2 that I want to take precedence over the shared-m2. (Assuming it really is the newest—otherwise shared-m2 should win)." I suppose someone could define a custom latest strategy that starts by doing the equivalent of "latest-revision" and then does tiebreakers based on "latest-time", but to me that smells of being a cop-out, like you haven't really settled on a versioning strategy. If I were in your situation, here's what I would do. I'm figuring that your shared repository is the destination for successful integration builds from your CI server. So say you're working locally on a project, bootcamp 3.0-SNAPSHOT, and the CI server is simultaneously publishing bootcamp 3.0-SNAPSHOT. Once a project is release-ready, it loses the –SNAPSHOT suffix, so 3.0 is considered later than 3.0-SNAPSHOT. I would set up a chain resolver that has returnFirst="true" and looks for the constituent resolvers in this order: 1. local 2. shared Your local work is always going to get picked up before what's on the shared server. And if you're actively working on bootcamp 3.0-SNAPSHOT and it's being depended upon by another project you're actively working on (such that you want to publish it and resolve it as a dependency), then it's only fair that you monitor your team's commits and make sure that, when someone commits a change to bootcamp, you sync up and make sure your work doesn't fall behind. On Tue, Aug 3, 2010 at 2:33 PM, Stephen Haberman <[email protected]>wrote: > Hi, > > I setup a chain of two ibiblio resolvers: > > shared-m2 > local-m2 > > And I have a new SNAPSHOT in local-m2 that I want to take precedence > over the shared-m2. (Assuming it really is the newest--otherwise > shared-m2 should win). > > The chain resolver docs assert it will go over each resolver and > pick the best/latest match, but this is not happening. > > The problem is in BasicResolver.getDependency: > > public ResolvedModuleRevision getDependency(DependencyDescriptor dd, > ResolveData data) > throws ParseException { > IvyContext context = IvyContext.pushNewCopyContext(); > try { > ResolvedModuleRevision mr = > data.getCurrentResolvedModuleRevision(); > if (mr != null) { > if (shouldReturnResolvedModule(dd, mr)) { > return mr; > } > } > > shouldReturnResolvedModule ignores changingPattern, so returns true, > and the local-m2 repo is never even checked for a newer snapshot. > > To me, if an artifact matches the changing pattern, it should be checked > for the latest in all resolvers, not just the first one found. > > Does this make sense? I'll file a bug if so. > > Thanks, > Stephen >
