-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite @ScalaSignature when shading #393
Conversation
…d a new processor for the scalasig.
|
||
class ScalaSigProcessor(rules: Seq[Rule]) extends JarProcessor { | ||
override def process(struct: EntryStruct): Boolean = { | ||
if (!struct.name.endsWith(".class") || struct.skipTransform) true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe allow *.sig
files here? - scala/scala#7712
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add it to the list. I have some reading up to do here.
Assuming shading is needed by tools other than sbt-assembly, I wonder if it might be useful to split this as a library on its own. When it starts supporting library, there wouldn't be a need to shade only at the end of fat JAR? If so shading could potentially stand on its own as a plugin (we can continue to provide integration from sbt-assembly since it seems to be a popular feature), or even a CLI tool. |
How about calling it Jar Jar Abrams? |
@eed3si9n About creating a new library (a can't reply to your comment, maybe we should move discussion to the issue?) We have only limited time to work on this so i was hoping to continue this as a part of sbt-assembly for now if you don't mind. We'll keep in mind that we want to extract in the future, once it gets some real life testing. You're right we are not limited to fat jars anymore when this is done. I used sbt-assembly to publish a shaded, fat, library in a test project to test this so currently it already fits that use case. I do like the idea of an sbt-shade plugin but i don't think we have time to build that now (and we do like to start using the shaded jars internally asap) Something else: I did run into an issue with ivy though which does not elide all the shaded dependencies. I actually don't know if ivy dependencies can be excluded for an additional artifact with classifier. Do you? |
I have a FAQ entry here that might be relevant - https://github.com/sbt/sbt-assembly#q-despite-the-concerned-friends-i-still-want-publish-fat-jars-what-advice-do-you-have |
Added test for EntryTable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing it's working thanks to the test.
Also I'm assuming you consent to releasing with the licensing terms of sbt-assembly? (MIT License) |
@eed3si9n |
I've split this into a new library - http://eed3si9n.com/jarjar-abrams |
Cool! Are you willing to add my company name (Simacan) to the blog post as I got to do most of the work in office hours? |
Absolutely. I just added a line. |
So shaded artifacts can be used as libraries. See #350
This adds an extra ScalaSigProcessor step to the current jarjar steps. I copied MainProcessor into JJProcessor and scalaified it to be able to add the extra step.
This is still a WIP. We plan to work on the in our next sprint. I made this PR to gather feedback
on the approach.
There are some things that need to be done:
Reason it i find it difficult to oversee which errors may get introduced by supporting the rename rules as they are right now.
I could really use some insight of a scala compiler developer to check if I've missed some obvious tags to rename.