2017-04-21Home
In the last part of Shade with SBT II,
One one more thing is
java.lang.VerifyErrorexceptions are thrown by JVM after the change. The work-around is adding-noverifyin the JVM options. I haven't yet found the root cause and the issue is logged at GEARPUMP-236.
I have a feeling that there will be a third episode of our story with sbt shade.
Now, here is the third episode. (The issue was resolved two months ago but my procrastination has been getting worse these days)
My colleague Karol found that the java.lang.VerifyError went away when forcing usage of asm 5.1. Thanks to his thorough investigation, I can just post his findings here.
As stated here: https://github.com/sbt/sbt-assembly/issues/205#issuecomment-278287602 there is probably a problem with shading.
In our tests the plugin regenerated the classes that shouldn't be impacted by shading. Moreover, the outcome of the operation made the classes not validated by JVM.
sbt-assembly we use (0.14.3) depends on jarjar(1.6.2) jarjar seems to be based on org.ow2.asm 5.0.4 (https://github.com/pantsbuild/jarjar/blob/master/lib/BUILD)
It seems like the bug is related to asm lib. The experiments show that after upgrading asm to 5.1.x
This was also confirmed by another user of sbt-assembly and fixed in sbt-assembly 0.14.4, and followed by asm upgrade in other downstream projects.
Ok, should this be the final episode ? I'm afraid not. Remember there is still an open question, sbt published maven file missing artifacts with multiple scopes.