forked from pantsbuild/pants
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Made shading rules accessible and configurable for jvm_binary.
jvm_binary() targets may now specify a shading_rules argument, which accepts a list of shading rules, which can be any of: shading_relocate() shading_exclude() shading_relocate_package() shading_exclude_package() The order of rules in the list matters, as typical of shading logic in general. These rules are powerful enough to take advantage of jarjar's more advanced syntax, like using wildcards in the middle of package names. E.g., this syntax will now work: # Destination pattern will be inferred to be # `[email protected].@2` shading_relocate('com.*.foo.bar.**') Which can also be done by: shading_relocate_package('com.*.foo.bar') I also added the ability to change the default `__shaded_by_pants__` prefix. # `__my_prefix__.com.foo.bar.@1` shading_relocate_package('com.foo.bar', shade_prefix='__my_prefix__.') The rules are implemented by `Shading.Relocate`, `Shading.Exclude`, `Shading.RelocatePackage`, and `Shading.ExcludePackage`. `Relocate` is the most generic, and acts as the base-class. It is essentially a factory for the Rule nametuple that previously existed in `Shader`. Rather than build off of the pre-existing `shade_class`, `shade_package`, `exclude_class`, and `exclude_package`, I made `Relocate` and friends more powerful, extensible and (I hope) intuitive concepts, and refactored the existing functions to use the new classes instead. They are wrapped in a Shading object rather than in the previous Shader object to keep the objects that make it into BUILD file aliases separate from those that do not. I also wistfully imagine a day when we can register BUILD file aliases recursively, which would let us use syntax like `Shading.Relocate` instead of shading_relocate, which would both be more consistent with things like `Duplicate` and `Skip` today, without polluting the global namespace. Today this is not possible, because while you *can* register `Shading`, and then access `Shading.*` in BUILD files, they don't make it into the BUILD dictionary when we generate docs. Testing Done: Added tests to tests/python/pants_test/java/jar:shader and tests/python/pants_test/java/jar:shader-integration Test project under testprojects/src/java/org/pantsbuild/testproject/shading and testprojects/src/java/org/pantsbuild/testproject/shadingdep. CI went green: https://travis-ci.org/gmalmquist/pants/builds/78593423 CI went green: https://travis-ci.org/gmalmquist/pants/builds/78809269 CI went green: https://travis-ci.org/gmalmquist/pants/builds/79349294 CI went green: https://travis-ci.org/gmalmquist/pants/builds/79354035 CI went green: https://travis-ci.org/gmalmquist/pants/builds/79369976 Bugs closed: 2121 Reviewed at https://rbcommons.com/s/twitter/r/2754/
- Loading branch information
1 parent
86603cd
commit c40fd43
Showing
29 changed files
with
806 additions
and
72 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -416,6 +416,70 @@ After building our `hello` example, if we check the binary jar's contents, there | |
org/pantsbuild/example/hello/world.txt | ||
$ | ||
|
||
Shading | ||
------- | ||
|
||
Sometimes you have dependencies that have conflicting package or class names. This typically occurs | ||
in the following scenario: Your jvm_binary depends on a 3rdparty library A (rev 1.0), and a 3rdparty | ||
library B (rev 1.3). It turns out that A happens to also depend on B, but it depends on B (rev 2.0), | ||
which is backwards-incompatible with rev 1.3. Now B (1.3) and B (2.0) define different versions of | ||
the same classes, with the same fully-qualified class names, and you're pulling them all onto the | ||
classpath for your project. | ||
|
||
This is where shading comes in: you can rename the fully-qualified names of the classes that | ||
conflict, typically by applying a prefix (eg, `__shaded_by_pants__.org.foobar.example`). | ||
|
||
Pants uses jarjar for shading, and allows shading rules to be specified on `jvm_binary` targets with | ||
the `shading_rules` argument. The `shading_rules` argument is a list of rules. Available rules | ||
include: <a pantsref='bdict_shading_relocate'>`shading_relocate`</a>, | ||
<a pantsref='bdict_shading_exclude'>`shading_exclude`</a>, | ||
<a pantsref='bdict_shading_relocate_package'>`shading_relocate_package`</a>, and | ||
<a pantsref='bdict_shading_exclude_package'>`shading_exclude_package`</a>. | ||
|
||
The order of rules in the list matters, as typical of shading | ||
logic in general. | ||
|
||
These rules are powerful enough to take advantage of jarjar's more | ||
advanced syntax, like using wildcards in the middle of package | ||
names. E.g., this syntax works: | ||
|
||
:::python | ||
# Destination pattern will be inferred to be | ||
# [email protected].@2 | ||
shading_relocate('com.*.foo.bar.**') | ||
|
||
Which can also be done by: | ||
|
||
:::python | ||
shading_relocate_package('com.*.foo.bar') | ||
|
||
The default shading prefix is `__shaded_by_pants__`, but you can change it: | ||
|
||
:::python | ||
shading_relocate_package('com.foo.bar', shade_prefix='__my_prefix__.') | ||
|
||
You can rename a specific class: | ||
|
||
:::python | ||
shading_relocate('com.example.foo.Main', 'org.example.bar.NotMain') | ||
|
||
If you want to shade everything in a package except a particular file (or subpackage), you can use | ||
the <a pantsref='bdict_shading_exclude'>`shading_exclude`</a> rule. | ||
|
||
:::python | ||
shading_exclude('com.example.foobar.Main') # Omit the Main class. | ||
shading_exclude_package('com.example.foobar.api') # Omit the api subpackage. | ||
shading_relocate_package('com.example.foobar') | ||
|
||
Again, order matters here: excludes have to appear __first__. | ||
|
||
To see an example, take a look at `testprojects/src/java/org/pantsbuild/testproject/shading/BUILD`, | ||
and try running | ||
|
||
:::bash | ||
./pants binary testprojects/src/java/org/pantsbuild/testproject/shading | ||
jar -tf dist/shading.jar | ||
|
||
Further Reading | ||
--------------- | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.