Scala 2.10 library class path referenced outside of project directory

[seglo]

Hi,

We have a Scala 2.10.0 CLI tool that we deploy with sbt-start-script (0.7.0). However, when we stage the project, deploy it, and attempt to run it we throw exceptions related to a missing scala-library 2.10.0 jar. When we include this jar in the /lib directory of our sbt project everything works as expected (it's included in the package and referenced in the start script class path). Should sbt-start-script not always include and reference the scala-library jar in the end-result package?

We do not have this problem with a similar project using sbt-start-script 0.6.0 and using scala 2.9.2.

Regards,

Sean

[havocp]

If I remember, the start-script plugin isn't moving jars around at all, just embedding the classpath from sbt in the script. It sounds like I might need a lot of your setup to be able to reproduce. But you can probably narrow down the problem by looking at where exactly it fails for 2.10 and why it works for 2.9:

• if you open your project in sbt, and look at "show dependency-classpath" is the scala jar on there and at what location?
• if you "show relative-dependency-classpath-string" is a still-valid scala jar location listed?
• if you look at the start script itself, is the scala jar mentioned in the script?
• where are the scala jars in your development tree?
• where are the scala jars once deployed?

Then you can figure out whether you're getting a bad classpath, bad relative classpath, or just are losing the jar somehow when deploying; and see what's different from 2.9 to 2.10

Maybe after narrowing it down it would be easy to make a test case or just tell me what's wrong.

[seglo]

Thanks for the tips.

The scala-library.jar was shown in the "show dependency-classpath" call, but it's referenced from within the .sbt directory of a user home directory (in this case, the tomcat7 user on the build server): /usr/share/tomcat7/.sbt/boot/scala-2.10.0/lib/scala-library.jar. Whereas the rest of my dependencies are referenced in the project's lib_managed directory. After closer inspection of the start file, as you mentioned this classpath is what's in the start script so when this package is deployed to another machine the library can't be found!

"show relative-dependency-classpath-string" will also reference the the scala-library.jar in the .sbt directory using an absolute path.

Other than just sticking scala-library.jar in lib (our present workaround) do you have any suggestions of how I can get the scala-library.jar referenced from the project instead of my local .sbt directory?

[seglo]

I updated the title of the issue accordingly.

[havocp]

Thanks for digging in. So I guess right now sbt-start-script doesn't really try very hard to make a "bundle" (it doesn't try to pull all dependencies into a deployable artifact that can move to another system), in fact there are a couple of other plugins that sound like they are more directly along those lines (https://github.com/guardian/sbt-dist-plugin or https://github.com/twitter/sbt-package-dist in a quick google). The one "bundling" concession in sbt-start-script is that it tries to make the classpath entries relative so you can copy the built source tree to another location, but it doesn't do any copying of jars that can't be made relative.

The origin of sbt-start-script is Heroku and I suspect this happens to work on there because Heroku's build scripts move sbt home (your /usr/share/tomcat7/.sbt/boot) into the source tree so paths into it can be made relative. You can see that at work in this script used to build sbt project on Heroku: https://github.com/heroku/heroku-buildpack-scala/blob/master/bin/compile

I guess what we could do here is, if an item on the classpath can't be made relative, we could copy it into lib_managed or somewhere else like that. It seems like it could make sense, but it might take me a while to have the cycles to look at what's involved.

As a short-term workaround I think you could maybe use the Heroku approach (basically, move the sbt home from ~/.sbt to somewhere inside your build tree, so it gets copied around with everything else).

The downside of this is simply that any plugins or caching you have in ~/.sbt would not be shared with other projects.

[baloo]

Hi,

I hit the same issue and i tried every plugin quoted in the comment above. No much solutions there neither.

What i did is I implemented a quick fix of potential solution. You may see code here:
baloo/sbt-start-script@49ee626...e21d2f0

A repository for it is available here:
http://evening-citadel-1625.herokuapp.com/

I only implemented the solution for jar bundle. That said, is the solution used a correct one ? If I do implement this solution with a SetttingKey (enable/disable jar copy), would you be interested in it ?

You may try directly the solution with:

• project/plugins.sbt

resolvers += Resolver.url("start-script", url("http://evening-citadel-1625.herokuapp.com/"))(Resolver.ivyStylePatterns)

addSbtPlugin("net.superbaloo" % "sbt-start-script-local" % "0.7.0-SNAPSHOT")

• project/Build.scala

import com.typesafe.sbt.SbtStartScript

object Blah {
  // Something like 
  // settings ++ SbtStartScript.startScriptForJarSettings
}