Pantbuild Jarjar Archived

[vjkoskela]

The pantsbuild/jarjar project was recently archived. Since the Bazel rules in this project depend on pantsbuild/jarjar, I was wondering what the plans were for this project to continue supporting shading in Bazel?

Also, if anyone on this project has any insight into where the Bazel community stands on this feature I would appreciate some pointers. The only references I found to shading with Bazel actually just lead back here!

e.g,:

• https://groups.google.com/forum/#!topic/bazel-discuss/WStUENkLJzo
• How bazel deal with fat jar and relocating issue? bazelbuild/bazel#3011

I can post this elsewhere (Stackoverflow or bazel-discuss@) if that would be more appropriate.

The rules here have been very useful for building extensions to existing JVM infrastructure in Bazel in the presence of dependency conflicts. Thanks for making these available!

[johnynek]

I'm glad this has been useful to you. The fact that the repo is archived doesn't seem necessarily like a problem. jarjar is pretty old, and that repo was a copy of the code with some very minor changes anyway.

Are there bugs you are seeing that need to be fixed?

I'm happy to merge any PRs to point to more recent published jars that have any bugfixes. But so far, I think this works well enough.

[vjkoskela]

No bugs. However, in order to shade Google's GRPC package it looks like I need a few additional features. In fact, submitting a patch for one of these features is what prompted the archiving of the pantsbuild/jarjar project.

The first feature was to be able to rename resource files. GRPC which depends on netty which in turn embeds a native dependency in the JAR which requires a name derived from the shading rule used on the package name. Details about the netty shading can be found in netty-6665. My pull request for adding rename support is here:

pantsbuild/jarjar#52

The second snag that I hit was that GRPC relies on service providers declared in META-INF/services/ for its name resolvers. The defaults need to be relocated with the package path change. Alternatively, I could just package in new resource files, but seems somewhat hacky (and brittle should Google change the default). The processing of service providers through the mapper seems relatively simple as well; I can post a branch with the changes if you are interested.

[johnynek]

I see.

How is your rename different from rule? can't you accomplish what you want with a rule?

Anyway, I think your main question is "who owns jarjar now?" Maybe the answer, unfortunately, is no one.

I cannot step up to do that.

[vjkoskela]

Unfortunately, I was unable to achieve the rename operation using the existing rule. I believe it was a combination of the file name changing and not the path, and the file being a resource (e.g. non .class) which are treated differently. There may be a more elegant way to extend rule to build out rename support.

Completely understand and appreciate your prompt response. I figured there was a good chance it was going to go unowned. If this becomes a bigger part of job I'll see if I can roll jarjar into that cycle.