Incorrect classpath precedence for scala-xml #3405
Comments
|
Thanks for the detailed reproduction steps. I thought maybe the classpath is somehow messed up, but Here's a related observation from scala> scala.xml.NodeSeq.Empty.isInstanceOf[scala.xml.NodeSeq]
res0: Boolean = true
scala> scala.xml.NodeSeq.Empty.isInstanceOf[Serializable]
res1: Boolean = false |
|
Yep, I had checked the A few other interesting things I have found. This issue influenced how I set up my The scala-xml project itself gets something right, but not sure what. It appears that its |
|
Issue in the scala compiler is scala/scala-dev#291 |
|
there are multiple tickets on this, see scala/scala-xml#195 (comment) |
|
Looking at this again. I think the problem is that during def createClasspathResources(classpath: Seq[File], instance: ScalaInstance): Map[String, String] =
createClasspathResources(classpath, instance.allJars)
def createClasspathResources(appPaths: Seq[File], bootPaths: Seq[File]): Map[String, String] = {
def make(name: String, paths: Seq[File]) = name -> Path.makeString(paths)
Map(make(AppClassPath, appPaths), make(BootClassPath, bootPaths))
}
This puts compiler JARs into boot classpath. Is boot classpath for taking higher precedence than rt.jar? If so we'd likely just need Scala library here, and not the whole family (compiler, reflect)? |
|
This behavior goes back to 2010 - 600053b |
|
FWIW, Mark Harrah left us a note: https://github.com/sbt/sbt/wiki/Scala-modularization-and-classpaths It seems relevant. There was also this associated discussion on scala-internals https://groups.google.com/forum/#!msg/scala-internals/tT1pjH5GECE/1wtOZoG9bgQJ |
|
and it's all configurable..? https://github.com/sbt/zinc/blob/v1.1.1/internal/compiler-interface/src/main/contraband-java/xsbti/compile/ClasspathOptions.java /**
* Define boot {@link ClasspathOptions} where:
* 1. the Scala standard library is present in the classpath;
* 2. the boot classpath is automatically configured; and,
* 3. the Scala standard library JAR is fetched from the classpath.
*/
public static ClasspathOptions boot() {
return ClasspathOptions.of(true, false, false, true, true);
} |
Fixes sbt/sbt#3405 Ref scala/scala-xml#195 sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs: ```scala res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar) ``` This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user.
Fixes sbt/sbt#3405 Ref scala/scala-xml#195 sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs: ```scala res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar) ``` This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user. 1. new field loaderLibraryOnly is added to xsbti.ScalaInstance. 2. it is initialized to the library loader if the launcher creates it, otherwise create layered loader here. This aims to isolate the library loader, and retain the perf.
|
This is now fixed in sbt 1.1.2. |
Fixes sbt/sbt#3405 Ref scala/scala-xml#195 sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs: ```scala res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar) ``` This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user. 1. new field loaderLibraryOnly is added to xsbti.ScalaInstance. 2. it is initialized to the library loader if the launcher creates it, otherwise create layered loader here. This aims to isolate the library loader, and retain the perf.
Fixes sbt#3405 Ref scala/scala-xml#195 sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs: ```scala res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar) ``` This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user. 1. new field loaderLibraryOnly is added to xsbti.ScalaInstance. 2. it is initialized to the library loader if the launcher creates it, otherwise create layered loader here. This aims to isolate the library loader, and retain the perf.
While working on fixing a serialization bug in scala-xml, I have been able to convince myself that sbt 0.13.16 incorrectly places the project's scala-xml version per
libraryDependenciesAFTER the version of scala-xml that the scala compiler happens to pull in for sbt to use itself.steps
The high level procedure is you need to publish a local build of scala-xml and pull a sample project you can demo the behavior on.
problem
The application should run in sbt the same way it runs outside. Using
sbt run, you'll get something like the following:expectation
Running it after packaging with sbt-native-packager yields the expected result:
notes
sbt version: 0.13.16
macOS Sierra 10.12.6
Versions of everything:
The text was updated successfully, but these errors were encountered: