search

lightbend-labs / dbuild

Multi-project build tool, based on sbt.
https://lightbend-labs.github.io/dbuild
Other
83 stars 14 forks source link

Scala home generation in sbt-build is fragile and now wrong #46

Closed jsuereth closed 10 years ago

jsuereth commented 11 years ago

The current mechanism of generating scala-home assumes a few incorrect things:

  1. All necessary artifacts are in the org.scala-lang namespace
  2. Artifacts needed for scala-home are not cross-versioned.

The migration to modules in scala 2.11 has booted scala-xml and scala-parser-combinators out of the main repository. These are both cross versioned, have different versions than scala itself and different module ids. They are also both needed to run scaladoc, so they must be in the ScalaInstance in sbt.

Also, I'm unaware of whether or not resolving scala via Ivy (in 2.11) will work correctly, since the dependency information may be off. I have not tried it.

We have a few options here:

  1. Continue to use my hacky workaround (pending in a PR). Here we just look for random jars and make good guesses as to which should be included.
  2. Try to resolve the scala-compiler.jar artifact using ivy and all dependencies into the ScalaInstance.
  3. Try to embed inter-artifact dependencies in dbuild metadata, and use the scala-compiler artifact to resolve itself and all dependencies.

I think we should aim for option 2.

jsuereth commented 10 years ago

This may be closed without fixing due to an alternative solution. I'll let @cunei make that call based on his most recent work fixing the scala build system.

cunei commented 10 years ago

The code in #68 resolves the mismatch of cross version suffixes in modules and Scala core: the artifacts IDs are rewritten according to the selected "build.options.cross-version" suffix selection desired. The issues due to cyclic dependencies in modules are also resolved by the same pull request, and the generation of the scala instance is presently done according to 6821671eaad6e57c1191da6e25541cb45d199d53, which should be ok for the time being. I believe this ticket can be closed (it may be reopened later, in case any new factors should impact on the scalaInstance generation).