make evictions possible for transitive deps of sandboxed gens

[bjaglin]

Follow-up of scalapb/scalapb-validate#38 (comment)

Putting this up to open the discussion: would it make sense to have ScalaPB sandboxed plugins loaded with a version of the ScalaPB compiler posterior to the one they have been built with? I haven't done the work in sbt-protoc to support this (where it would be fairly easy to capitalize on the eviction happening in the meta project), but here is how it would look like on the plugin side: bjaglin/scalapb-validate@801215e.

[bjaglin]

cc @gontard for visibility

[bjaglin]

I had to change the parameter order as the Java signature of the overloads would be the same otherwise due to type erasure on Function1

[thesamet]

Few thoughts:

• There are some advantages for sandboxing plugins from one another: preventing binary compatibility issues and mimicking the way plugins run when packaged natively.
• I think that breakages due to coupling would (and should) be infrequent and all resolved by cutting an updated release? Is there more to the pain point leading to this issue?

[bjaglin]

Fair points, I guess the difference with other plugins is how fast ScalaPB is moving ;)

The main driver for opening this is that I fear that we won't be able to quickly adopt upcoming features (message transformations for example) because a third-party generator is lagging behind. For example, the latest stable release of akka-grpc at the time of the writing is still built against 0.10.8, released in August. Granted, that hasn't been a problem for us at the moment, so it's pure speculation.

What's frustrating is that from my understanding, there is simply no way to override the ScalaPB compiler version embedded in a sandboxed generator at the moment, at least through sbt-protoc. Maybe a middle-ground would be to add a classloaderExtraModules: Seq[Module] setting key in sbt-protoc to make it possible to evict what gets classloaded across all generators?