-
Notifications
You must be signed in to change notification settings - Fork 21
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
Reproduction test case with an shading issue #8
Conversation
f8457cf
to
bc5d12f
Compare
I forgot one folder outside of git. So the first build is completely irrelevant, but the latest one is: https://travis-ci.com/github/eed3si9n/jarjar-abrams/jobs/396423322#L488 |
@daddykotex Thanks for the reproduction.
I'm not really sure since I've only packaged the code contributed by @jeroentervoorde and others. I'd suggest you look into the output of scalap to pinpoint the exact bytecode in your trait. My guess is that all classes are renamed, but maybe some references to classes may not be handled by jarjar? If so I think it's possible to provide a visitor that would rewrite the bytecode. See test case in jarjar (https://github.com/pantsbuild/jarjar/blob/master/src/test/java/org/pantsbuild/jarjar/MethodRewriterTest.java). |
Thank you, I will look into it |
I see that the project is now in read-only, I may have to fork and publish a new version. |
Dropping this here as pieces of my investigation. I must say I'm learning as I go here. I've added a way to run
|
Running
|
|
@daddykotex you might try testing this against #15 and see if the update of the newer jarjar fixes this issue |
This works if you don't reference the "shaded" in the original diff --git a/sbtplugin/src/sbt-test/actions/trait/use/src/main/scala/Test.scala b/sbtplugin/src/sbt-test/actions/trait/use/src/main/scala/Test.scala
index 072aadc..3075135 100644
--- a/sbtplugin/src/sbt-test/actions/trait/use/src/main/scala/Test.scala
+++ b/sbtplugin/src/sbt-test/actions/trait/use/src/main/scala/Test.scala
@@ -2,7 +2,7 @@ package example
import shaded.example._
-class DependsOn extends shaded.example.ATraitWithAVal
+class DependsOn extends example.ATraitWithAVal
object ApplicationMain extends App {
new DependsOn Branch against master:
|
Going to close for now, please re-open if you think in error |
Amazing work @er1c thanks a lot. |
Do you know when the next release will be published? Thanks again |
@daddykotex hopefully later tonight |
Hi thanks for the library, it's currently saving our asses (I'm sad to say, but we have to shade some libraries).
While working with the library, we noticed one issue with it. This pull request only includes a reproduction case and hopefully the CI can run and show the error.
I would be more than happy to provide a fix for it. I would just like to ask if that's possible at all (I'm not sure because the issue seems to come from a low level compiler behaviour).
Here is the stack (explanation follows):
Let's say I'm trying to shade
com.example:some-library
. This library is a Scala library and it has atrait
defined like so:In this instance, the
val
inside the trait is compiled in a very specific way to be a Java interface. A setter will be introduced and called during initialization. The setter will look like:When we shade, I believe we should rename those as well, because otherwise, extending the shaded trait raise an error like shown above. (more info at https://stackoverflow.com/questions/43446423/using-val-in-scala-trait).
Do you think it's possible to fix this, if yes, let me know, I'll look into it more carefully and try to fix it.