rtimush
Feature request: new tasks "useLatestReleases", "useLatestVersions", etc.
I'd like to raise a feature request for something similar to what is provided in the versions-maven-plugin, for example:
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?
I am not certain about this approach when it comes to dependency management because:
- It doesn't sound like a sane idea to have a separate
.sbtfor each plugin. Sounds more like a lazy workaround. - 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
.sbtfile really solves the problem.
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.
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.
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.
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.
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.
