Cross compile code with Scala 2.13.x #807
Conversation
|
Some of current test issues: [error] higherkindness.mu.rpc.http.GreeterDerivedRestTests
[error] higherkindness.mu.rpc.http.GreeterRestTests
[error] (http / Test / test) sbt.TestsFailedException: Tests unsuccessful |
Going to do it in a separate PR
Codecov Report
@@ Coverage Diff @@
## master #807 +/- ##
==========================================
- Coverage 71.75% 71.63% -0.12%
==========================================
Files 69 69
Lines 1048 1033 -15
Branches 13 19 +6
==========================================
- Hits 752 740 -12
+ Misses 296 293 -3
Continue to review full report at Codecov.
|
| `health-check-unary`, | ||
| `example-health-client`, | ||
| `example-health-server-monix`, | ||
| `example-health-server-fs2`, |
There was a problem hiding this comment.
How do we decide which modules are "core" and which are not? Example projects don't seem very core to me.
Is coreModules actually the list of projects that the docs depend on? If so, let's rename it.
There was a problem hiding this comment.
I've renamed the others by something more explicit. Basically, the modules that are not part of the coreModules are those that cannot be cross-compiled to Scala 2.13.x.
build.sbt
Outdated
| `example-routeguide-protocol`, | ||
| `example-routeguide-common`, | ||
| `example-routeguide-runtime`, | ||
| `example-routeguide-server`, | ||
| `example-routeguide-client`, | ||
| seed |
There was a problem hiding this comment.
seed is also an example project, right? Shall we rename it to example-seed for consistency?
|
|
||
| lazy val root = project | ||
| .in(file(".")) | ||
| .settings(name := "mu-scala") | ||
| .settings(noPublishSettings) | ||
| .aggregate(allModules: _*) | ||
| .dependsOn(allModulesDeps: _*) | ||
| .aggregate(coreModules: _*) |
There was a problem hiding this comment.
Oh, root doesn't aggregate all the example projects any more? I'm not sure that's a good idea. I can imagine myself doing a refactoring, running compile or test and thinking everything's ok, but actually my refactoring has broken half the example projects.
There was a problem hiding this comment.
I think the amount of modules is currently insane. My proposal would be to move all the examples to its own repository.
lazy val nonCrossedScalaVersionModules: Seq[ProjectReference] = Seq(
`benchmarks-vprev`,
`benchmarks-vnext`,
`example-todolist-protocol`,
`example-todolist-runtime`,
`example-todolist-server`,
`example-todolist-client`
)Currently, the root module cannot aggregate the modules above because they cannot be cross-compiled with Scala 2.13.x. That's why I split the aggregation into two different modules and added to Travis CI the proper check to make sure nothing is broken before going to master.
There was a problem hiding this comment.
Proposal filed at #817
There was a problem hiding this comment.
I think the amount of modules is currently insane.
Agreed. It makes the CI painfully slow, and navigating the code is really difficult with the library and the examples all mixed together in the same repo. It makes the examples less discoverable as well.
project/ProjectPlugin.scala
Outdated
| scalacOptions ++= customScalacOptions, | ||
| scalaVersion := V.scala213, | ||
| crossScalaVersions := Seq(V.scala212, V.scala213), | ||
| scalacOptions ~= (_ filterNot Set("-Xfuture", "-Xfatal-warnings").contains), |
There was a problem hiding this comment.
Why are we disabling fatal-warnings?
There was a problem hiding this comment.
Also you can write this more simply as scalacOptions --= Seq("-Xfuture", "-Xfatal-warnings")
There was a problem hiding this comment.
Why are we disabling fatal-warnings?
Current code won't compile as it is. If we want to enable it, I propose to do it in a separate PR.
Also you can write this more simply as scalacOptions --= Seq("-Xfuture", "-Xfatal-warnings")
👍 263c3a5
|
I'm a little confused about the rearrangement of the modules, but overall this looks great! Thank you for tackling it. |
What this does?
Closes #787
Checklist