Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to specify classpath for compiler plugins #4841

Closed
scabug opened this issue Jul 27, 2011 · 6 comments
Closed

Option to specify classpath for compiler plugins #4841

scabug opened this issue Jul 27, 2011 · 6 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jul 27, 2011

Plugins get their own class loader, but there is not currently a way to put jars in this class loader except by declaring a jar to be a plugin. If the jar doesn't contain a plugin, however, a warning is printed.

This enhancement requests either removing the warning (not the preferred solution) or adding a new option, such as '-Xpluginscp' that allows specifying additional jars to be available to plugins. A patch is attached to demonstrate this.

@scabug
Copy link
Author

@scabug scabug commented Jul 27, 2011

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

@scabug
Copy link
Author

@scabug scabug commented Jun 11, 2012

@adriaanm said:
Feel free to re-assign to reviewer.

@scabug
Copy link
Author

@scabug scabug commented Jun 11, 2012

@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.

@scabug
Copy link
Author

@scabug scabug commented Nov 20, 2013

@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

@scabug
Copy link
Author

@scabug scabug commented Nov 21, 2013

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

scala/scala#3169

@scabug
Copy link
Author

@scabug scabug commented Nov 21, 2013

@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.

@scabug scabug closed this Dec 12, 2013
@scabug scabug added this to the 2.11.0-M8 milestone Apr 7, 2017
@scala scala deleted a comment from scabug Jun 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants