{"push_id":785269313,"size":1,"distinct_size":1,"ref":"refs/heads/gmalmquist/shading-support-for-jvm-binary","head":"3695dcb332ae9ac69a141c99777f0001c0a4ed52","before":"0d0e90ba299637a24a8a28aa2b3d5aea8bdbe3c4","commits":[{"sha":"3695dcb332ae9ac69a141c99777f0001c0a4ed52","author":{"email":"de99e07effbff7db9225ec5b93e59cadc57850c4@squareup.com","name":"Garrett Malmquist"},"message":"Made shading rules accessible and configurable for jvm_binary.\n\njvm_binary() targets may now specify a shading_rules argument,\nwhich accepts a list of shading rules, which can be any of:\n\n    shading_relocate()\n    shading_exclude()\n    shading_relocate_package()\n    shading_exclude_package()\n\nThe order of rules in the list matters, as typical of shading\nlogic in general.\n\nThese rules are powerful enough to take advantage of jarjar's more\nadvanced syntax, like using wildcards in the middle of package\nnames. E.g., this syntax will now work:\n\n    # Destination pattern will be inferred to be\n    # `__shaded_by_pants__.com.@1.foo.bar.@2`\n    shading_relocate('com.*.foo.bar.**')\n\nWhich can also be done by:\n\n   shading_relocate_package('com.*.foo.bar')\n\nI also added the ability to change the default\n`__shaded_by_pants__` prefix.\n\n    # `__my_prefix__.group.name.rev.jar.com.foo.bar.@1`\n    shading_relocate_package('com.foo.bar', shade_prefix='__my_prefix__.')\n\nThe rules are implemented by `Shading.Relocate`, `Shading.Exclude`,\n`Shading.RelocatePackage`, and `Shading.ExcludePackage`.\n\n`Relocate` is the most generic, and acts as the base-class. It is\nessentially a factory for the Rule nametuple that previously\nexisted in `Shader`.\n\nRather than build off of the pre-existing `shade_class`,\n`shade_package`, `exclude_class`, and `exclude_package`, I made\n`Relocate` and friends more powerful, extensible and (I hope)\nintuitive concepts, and refactored the existing functions to use\nthe new classes instead.\n\nThey are wrapped in a Shading object rather than in the previous\nShader object to keep the objects that make it into BUILD file\naliases separate from those that do not. I also wistfully imagine\na day when we can register BUILD file aliases recursively,\nwhich would let us use syntax like `Shading.Relocate` instead of\nshading_relocate, which would both be more consistent with things\nlike `Duplicate` and `Skip` today, without polluting the global\nnamespace. Today this is not possible, because while you *can*\nregister `Shading`, and then access `Shading.*` in BUILD files,\nthey don't make it into the BUILD dictionary when we generate docs.","distinct":true,"url":"https://api.github.com/repos/gmalmquist/pants/commits/3695dcb332ae9ac69a141c99777f0001c0a4ed52"}]}