This is an important question, thanks for asking!
I think that the Scala Platform cannot be completely closed and the whitelist proposed by you and @odersky could work. I would accept
scala-reflect, and the lowest maintained JDK version supported by the latest Scala major version. As the SPP proposes, modules need to be cross-compiled with the latest two major Scala versions. As of now, this means
2.12.x. In this case, although
2.11.x is compatible with JDK6, JDK7 and JDK8, the latest version
2.12.x requires JDK8. Therefore, the Scala Platform needs to keep up with
2.12.x and only allow JDK8 libraries. This is unfortunate for 2.11 users that may want to run the Platform, but when these breaking changes happen in the compiler the Scala Platform has to honor them.
macro-paradise is going to stay for a while since Scala Meta is its official replacement but it’s not ready yet. I think it’s reasonable to whitelist it for the first Scala Platform version (which will be
0.1.x) and even more if Meta doesn’t stabilize before that; and then ask modules to use Scala Meta instead for the
1.0.0 release. We would do a similar migration path for
scala-library when the split core-platform is materialized in
If we have these whitelisted versions, it’s not necessary to have a tool to check collision of dependencies (different versions of the same artifact). Otherwise, the Scala Platform should have a tool that checks this and notifies mantainers.
I’m not sure how people feel about these rules, they may be a little bit strict. This strictness in my opinion is a feature of the Scala Platform rather than a disadvantage: we want our users to know that we honor stability. Bringing in uncontrolled external dependencies could cause severe problems to both users and module contributors/maintainers. Because of this, I’m not sure that @martijnhoekstra’s observation would lead to a good solution. Considering runtime dependencies part of the Platform not only is odd, but could turn out to be dangerous…