Support for shading deploy jars #13259
Comments
I'll point out that (I think) shading for user binaries was never implemented in Pants V1 although it would be useful as you suggest. The driving need then was for jvm tools that ran using a mixture of their required classpath and user classpath items. |
It was: https://v1.pantsbuild.org/jvm_projects.html#omitting-or-shading-the-contents-of-a-binary |
This is a Request For Comments with a PoC with a minimal implementation for supporting shading rules in JVM targets, i.e.: the `deploy_jar` target.
The implementation is straightforwardly based on JarJar and it adds three aliases to the build files to help defining each of the given rules.
For example, when shading a `deploy_jar`, a `BUILD` file would look something like:
```python
deploy_jar(
name="my_deploy_jar",
shading_rules=[
shading_rename(pattern="com.fasterxml.jackson.**", replacement="mycompany.jackson.@1"),
shading_zap(pattern="javax.servlet.**"),
shading_keep(pattern="org.apache.spark.**"),
]
)
```
The implementation doesn't solve the potential problems that may show up when merging files from different JARs that are at the same relative location in each of those files. That is being left out-of-scope of this implementation.
Fixes #13259.
[ci skip-build-wheels]
[ci skip-rust]
#12796 added support for building deploy ("fat") jars. Most usecases of deploy jars also need the ability to shade the contents of the jar (in order to deploy it to Hadoop, Spark, or other environments without classloader isolation).
Most likely this will involve using 9and likely resurrecting) our fork of
jarjar... but it's also possible that modern alternatives have emerged, so we should look at what other tools are doing first.The text was updated successfully, but these errors were encountered: