Conversation
…ue. #1514 * Create a project "common" which publishes a "bad" artifact. * Resolve project "dependent" which resolves the "bad" artifact into the cache. * Publish a new "common" snapshot to a diffferent repository (publishLocal) * Attempt to build the new project, leading to issues.
…ver.
Adds `lastestSnapshots` flag to `updateOptions`, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first `-SNAPSHOT` revision it found along the chain. When is enabled (default: ), it will look into all resolvers on the chain, and compare them using the publish date.
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:
updateOptions := updateOptions.value.withLatestSnapshots(false)
Ivy by default uses latest-revision as the latest strategy. This strategy I don't think takes in account for the possibility that a changing revision may exist in multiple repositories/resolvers with having identical version number like 0.1.0-SNAPSHOT.
The implementation is a bit hacky, but I think it attacks the core of this problem.
Member
There was a problem hiding this comment.
Why the filter? What else could be in there?
Member
Author
There was a problem hiding this comment.
Ivy doesn't use Java 5 generics, so we get like Collection all the time.
Member
|
LGTM!!!! |
eed3si9n
added a commit
that referenced
this pull request
Jun 24, 2015
eed3si9n
added a commit
that referenced
this pull request
Dec 14, 2015
#1520 originally fixed #1514 by reimplementing part of chain resolver to check all resolvers to find the latest snapshot artifacts. This behavior did not work well with Maven repositories where sbt was failing to calculate the correct publication dates. Now that #2075 fixes the Maven integration issue we should enable this flag back again. The build user can opt out by: updateOptions := updateOptions.value.withLatestSnapshots(false)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1514, #321
Adds
lastestSnapshotsflag toupdateOptions, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first-SNAPSHOTrevision it found along the chain. WhenlastestSnapshotsis enabled (default:true), it will look into all resolvers on the chain, and compare them using the publish date.The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:
Ivy by default uses latest-revision as the latest strategy. This strategy I don't think takes in account for the possibility that a changing revision may exist in multiple repositories/resolvers with having identical version number like 0.1.0-SNAPSHOT.
The implementation is a bit hacky, but I think it attacks the core of this problem.