Imported From: https://issues.scala-lang.org/browse/SI-4841?orig=1
Reporter: @harrah
Attachments:

• pluginscp.patch (created on Jul 27, 2011 2:23:57 AM UTC, 2707 bytes)

@harrah said:
I assume this isn't happening: https://groups.google.com/forum/#!topic/scala-internals/x7kBYq6oDkI.

If not, all I would do is update the patch to compile against master and submit a pull request instead. If that is fine, I'll do that. Otherwise, I'd reassign back to scala-reviewer.

@som-snytt said:
Adding a manifest Class-Path to the plugin.jar works in the usual way.

It seems to me that the reason to have an option for a plugin class path is that two plugins have conflicting dependencies and you have to keep them separate; otherwise, using the compiler's class path suffices.

If a plugin-specific path is deemed a requirement, maybe make -Xplugin a path instead of a location. One of the elements of the path better contain a plugin descriptor. The first lucky location to define a plugin wins. That path is used to load it, of course.

E.g., -Xplugin:plugin1.jar:dep1.jar,plugin2.jar:dep2.jar,something.jar:plugin3.jar

@som-snytt said:
This implements that behavio(u)r:

scala/scala#3169

@harrah said:
The compiler class loader can't be cached if a plugin's classpath is included on the compiler classpath. The manifest Class-Path isn't reliable when distributing plugins. -Xplugin as a path seems sensible to me.