Embedded Scala REPL inherits parent classpath

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 paren开发者_Python百科t 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.