Make classpath configurable

[tgpfeiffer]

In my setup, some dependencies are marked as "provided" because they are actually provided by the environment at runtime (Spark/Hadoop) and they should not go into the application jar as build by sbt assembly. To have them in the classpath when using sbt run, I can use the trick from http://stackoverflow.com/a/21803413/3663881. To achieve the same when running with the script generated by sbt start-script, there seems to be no such easy solution.

Actually,

SbtStartScript.StartScriptKeys.relativeFullClasspathString in Compile <<=
  (SbtStartScript.StartScriptKeys.startScriptBaseDirectory, fullClasspath in Compile) map relativeClasspathStringTask

would do the trick quite well, but as relativeClasspathStringTask() is private, I had to create a verbatim copy of relativeClasspathStringTask(), relativizeFile(), and directoryEqualsOrContains(). That is quite "not so good" and it would be nice to have a possibility to configure which classpath is used.

[havocp]

This plugin hasn't seen much maintenance since most people have switched to sbt-native-packager - have you tried that out?

[tgpfeiffer]

No, actually I haven't. This plugin seemed much simpler to get me started, as I only want a faster version of "sbt run".

[havocp]

This one is simpler, but also has far fewer features. Instructions to convert are in the README https://github.com/sbt/sbt-start-script/blob/master/README.md though I haven't updated them in a long time, so it's possible they are slightly stale. I don't know if sbt-native-packager makes this task easier but you would likely get an answer on stackoverflow if you ask.
Another option could be to drop https://github.com/sbt/sbt-start-script/blob/master/src/main/scala/com/typesafe/sbt/SbtStartScript.scala into your project/ directory and edit it a bit to do what you want...
or take this plugin and run with maintaining it, but that's a pretty big yak shave for a simple problem :-)