Implemented manifest-based class-paths.

If you run a jar directly, like

  scala foo.jar

Then if a Class-Path attribute is present in the jar manifest, the
classpath will be constructed from that instead of the arguments. Some
things remain to be determined, like whether it's supposed to replace
a classpath given on the command line or supplement it, and whether
the master jar should be on the classpath or only and exactly the jars
listed in the manifest.

There's a really nice test case, which won't be run of course, but I
can't stand going any further without tests for these hard to test on
all platforms things. The faux .check file shows what I see.

Closes SI-4355, review by harrah.

1 files changed, 8 insertions, 0 deletions

diff --git a/src/compiler/scala/tools/nsc/io/Jar.scala b/src/compiler/scala/tools/nsc/io/Jar.scala
index ad1598a85d..bbed5a9e20 100644
--- a/src/compiler/scala/tools/nsc/io/Jar.scala
+++ b/src/compiler/scala/tools/nsc/io/Jar.scala
@@ -40,7 +40,15 @@ class Jar(file: File) extends Iterable[JarEntry] {
 
   lazy val jarFile  = new JarFile(file.jfile)
   lazy val manifest = withJarInput(s => Option(s.getManifest))
+
   def mainClass     = manifest map (f => f(Name.MAIN_CLASS))
+  /** The manifest-defined classpath String if available. */
+  def classPathString: Option[String] =
+    for (m <- manifest ; cp <- m.attrs get Name.CLASS_PATH) yield cp
+  def classPathElements: List[String] = classPathString match {
+    case Some(s)  => s split "\\s+" toList
+    case _        => Nil
+  }
 
   def withJarInput[T](f: JarInputStream => T): T = {
     val in = new JarInputStream(file.inputStream())