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.
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 usingsbt run, I can use the trick from http://stackoverflow.com/a/21803413/3663881. To achieve the same when running with the script generated bysbt start-script, there seems to be no such easy solution.Actually,
would do the trick quite well, but as
relativeClasspathStringTask()is private, I had to create a verbatim copy ofrelativeClasspathStringTask(),relativizeFile(), anddirectoryEqualsOrContains(). That is quite "not so good" and it would be nice to have a possibility to configure which classpath is used.