Modify version resolution s.t. we select the highest version possible

petroseskinder commented 7 years ago

Resolves #16.

Context

When faced with multiple potential versions, Maven selects the highest matching version, if a range is provided. The resolver did not. Instead, it would guess a potential version, without examining the available versions. The following design document discusses the issues present with the prior implementation. In addition, it proposes a solution for how to incorporate backtracking and SAT solving to resolve versioning conflicts.

What has changed?

Commit 1: Resolver was refactored so that SHA1 downloading and versioning were in separate classes. Relevant tests were also moved to their own separate classes
Commit 2: Version resolution was changed. Now, when requesting a version for an artifact, resolver scrapes maven central for all available versions, and selecting a version that fits within the provided range. Prior implementation had a number of edge cases that were not in compliance with how maven specs. Tests were added for each case.
- For example, (2,3) would throw an exception. "2.3" did not get the highest version. [2.3,) would return 2.3, irrespective of whether there were later versions. (,4.0] would unintentionally throw an exception. Not providing a version would also throw an exception, instead of returning highest version.

What is not implemented?

Support for Sequences of Versions: For example, one can provide a version specification like "(,1.1),(1.1,). This excludes version 1.1.
Support for Non-maven central repositories:
Version Conflict Resolution: This is a naive greedy implementation. The emphasis is on resolving versions for a given artifact. It is unknown how it will behave on POM files or multiple artifacts with conflicting versions. However, it will perform no worse, than the existing implementation.

Reviewers: @kchodorow, @katre CC: @hhclam, @jin

bazel-io commented 7 years ago

Can one of the admins verify this patch?

petroseskinder commented 7 years ago

Sorry for the large CL. Much of the 600 lines comes from refactoring and writing test cases.

petroseskinder commented 7 years ago

per our offline discussion, i'm going to close this pull request.

bazelbuild / migration-tooling