Show version breadcrumbs

[ben-manes]

@tkruse suggestion is to display the version upgrade path, e.g.

- org.mockito:mockito-all [1.10.18 -> 1.10.19 -> 1.11.5 -> 2.1.6]

meaning the latest version with same major and minor, the latest with same major, and the global latest. That would serve the same purpose, but go without additional configuration.

The trick for the expanded version list is getting it through the Gradle API. Gradle expects to select an exact version or the latest that meets a criteria. We could have a rule that rejects all versions (except for the current) and captures the version list. This would be a roundabout way to get the information, but would let us show the transition flow.

[jochenberger]

Wouldn't we have to do multiple resolution steps to get that information, i.e. one for 1.10.+, one for 1.+ and one for +?

[ben-manes]

Yep, it would be multiple and we'd have to do it using a ComponentSelection rule that captures the candidate's version and rejects until it reaches the build's current version. The more out of date the dependency is, the more versions have to be resolved and the slower the task takes.

I'm pretty confident we can get this to work, but I'm not sure if most users would appreciate the enhancement or prefer a faster check. @tkruse idea was that this approach would replace users adding a custom component selection rule because they could filter out betas by inspection.

What do you think we should do?

[tkruse]

As long as multiple calls are required, I would not want this as standard behavior. I am not sure how easy or convenient it is to add some switch such that users may run with '--verbose' or something to get more information

[ben-manes]

Unfortunately it would require multiple calls because Gradle doesn't expose to us the version metadata (e.g. from maven_metadata.xml). It appears that when evaluating candidates it retrieves the candidate version's metadata (e.g. pom.xml) so an extra http request is required per candidate evaluation. This is then cached, but due to the sequential nature of the resolution process this is slow.

Its probably time to bite the bullet and add a configuration block (dsl extension). I had avoided that in the past because I didn't want a dozen toggles to hack around api quirks. I think the ones we'd need now all reasonably fit into Gradle's api instead of working around it. I'm thinking we'd want options like:

• breadcrumbs: boolean to display version path (is there a better name?)
• resolutionStrategy: block for rules only applied to the task's copied configuration
• versionPattern: A regex string for the version as a one-line alternative to the block
• revision: The revision filter (integration, milestone, release)
• misc reporting: #12, #70, formatters, etc.

When possible these could be defined on the command line too.