As asked in this thread on the Scala mailing list, how can I create an embedded Scala REPL that inherits the classpath of the parent program? Suppose the parent Scala program is launched using scala -cp <classpath> ...
; can <classpath>
be accessed as a string and used to initialize the embedded REPL? (The Java classpath, available via System.getProperty("java.class.path")
, appears to differ from the Scala classpath.)
Alternatively, perhaps the embedded Scala REPL can inherit or construct its ClassLoader from the parent process (Michael Dürig's ScalaDays 2010 talk might be relevant). Is this the recommended approach?
I'm trying to do the same thing, and I just found a way my out by Googling:
lazy val urls = java.lang.Thread.currentThread.getContextClassLoader match {
case cl: java.net.URLClassLoader => cl.getURLs.toList
case _ => error("classloader is not a URLClassLoader")
}
lazy val classpath = urls map {_.toString}
The above code gets you the classpath in current context.
settings.classpath.value = classpath.distinct.mkString(java.io.File.pathSeparator)
Put that into your settings.classpath
and you should be able to fire up dispatch or whatever library you need.
set the usejavacp
property to true:
val settings = new scala.tools.nsc.Settings
settings.usejavacp.value = true
There does not seem to be an easy way to access the "Scala classpath" from within a running Scala program (in contrast, the "Java classpath" is available through the java.class.path
system property). One would like to access, e.g., the field Calculated.userClasspath
in the instance of scala.tools.PathResolver
, but the latter does not seem accessible. Perhaps the easiest work-around is to modify the scala
launch script to store the -classpath
parameter string in an environment variable.
Assuming the desired Scala classpath can be determined, it can be passed to the embedded Scala interpreter via:
settings.classpath.value = ...
Update: although the Scala classpath string may not be directly attainable from the Scala runtime, @Eugene points out that it can be extracted from the context classloader. Thanks.