Feature request: new tasks "useLatestReleases", "useLatestVersions", etc.

[leesah]

I'd like to raise a feature request for something similar to what is provided in the versions-maven-plugin, for example:

• versions:use-latest-releases
• versions:use-latest-versions

[leesah]

Did some researching. Like what the author of sbt-release said in the README, it doesn't seem to be a good idea to directly update the build.sbt as it's not in a strictly structural format.

Then how do you think about introducing something like a dependencies.sbt?

[leesah]

I am not certain about this approach when it comes to dependency management because:

1. It doesn't sound like a sane idea to have a separate .sbt for each plugin. Sounds more like a lazy workaround.
2. The dependencies can have much more complex syntax than just a version definition (there can be a lot of exclusions at least) so I'm not sure a separate .sbt file really solves the problem.

[rtimush]

Related PR: #68

[leesah]

I've been trying things out today. I agree on the argument in #68 that updating build.sbt using string matching is fragile, so is any .sbt even though separated. So my proposal is to manage a separate managed-dependencies.xml and import to build.sbt using

scala.io.source.fromfile("managed-dependencies.xml")

Please comment.

[leesah]

I've been doing some experiments. When I remove the libraryDependencies ++= Seq(...) statement and replace with ivyXML := <dependencies>...</dependencies>, compilation fails:

[error] (compile:compileIncremental) scala.reflect.internal.MissingRequirementError: object scala in compiler mirror not found.

And if I run show libraryDependencies in sbt, only the very basic libraries:

> show libraryDependencies
[info] * org.scoverage:scalac-scoverage-runtime_2.11:1.1.0:provided
[info] * org.scoverage:scalac-scoverage-plugin_2.11:1.1.0:provided
[info] * org.wartremover:wartremover:1.1.1:plugin->default(compile)
[info] * com.sksamuel.scapegoat:scalac-scapegoat-plugin_2.11:1.2.1:compile
[info] * org.scala-lang:scala-library:2.11.7
[info] * org.psywerx.hairyfotr:linter:0.1.14:plugin->default(compile)

I think this suggests sbt is not merging library dependencies from different sources. When ivyXML is assigned a value, libraryDependencies is not used at all. Which means I can't move only the dependencies that I want to manage with the plugin into a separate xml file, but have to move all of them, plus the basics like scala-library etc. That's too much of change on an existing project, nobody would like it.

To solve this problem, one way I can think of is to transform the ivyXML into a Seq and merge it with libraryDependencies (or the other way around into ivyXML). Should work, technically. But then there's another issue: I don't think the schema supports anything equivalent to the %% in a build.sbt.

In summary, I don't think this separate ivy.xml solution is the right direction to continue on.

[rtimush]

Hi @leesah. To be honest I don't think anyone would be willing to replace their SBT dependency definitions with XML. One possible direction for exploration is to parse a build file (Scalameta?) to find where the version values are declared. This will allow upgrading dependencies even if their versions are declared as variables.

[leesah]

I totally agree. That is for sure the perfect solution. I tried to work around it because I never worked with anything like a compiler etc., I don't really know where to start. I'll try to find some reading materials and see if I could manage.

[dwijnand]

One possible direction for exploration is to parse a build file (Scalameta?) to find where the version values are declared. This will allow upgrading dependencies even if their versions are declared as variables.

💯 That's one of the things I was hoping (finally) upgrading sbt to Scala 2.12 would allow for.