Open Oduig opened 1 year ago
This project is aimed at publishing libraries with shaded jars and will modify the publish/publishLocal behavior. I agree that sbt-assembly should be a bit smarter to shade only transitive dependencies. You can always use .inAll
in sbt-assembly to rewrite any class.
Background In our project we are using
sbt-assembly
to generate a fat JAR for Spark. Our Spark deployment has a very large body of libraries built-in, which are often out of date and conflict with libraries in our own project. We regularly run into the cryptic errorjava.lang.VerifyError: Cannot inherit from final class
which points to a dependency conflict. To solve this, we manually go through the dependency tree to find the conflicting classes, and shade them by class package.This is especially tiresome for large dependencies which pull in nested dependencies. It would be better to shade by library rather than by class package, and it appears
sbt-shading
perfectly solves that problem!Question
When I run
sbt assembly
, the project is built as normal, and none of the libraries inshadedModules
are shaded.Can we use
sbt-shading
withsbt-assembly
somehow? Alternatively, what is the best way to create a fat JAR withsbt-shading
?