Closed ryan-williams closed 8 years ago
Ah sorry I have this fixed locally - spark <2.0 brings in an older version of breeze. I fixed this by adding an additional relocation as follows
<relocation>
<pattern>breeze.linalg</pattern>
<shadedPattern>org.hammerlab.breeze</shadedPattern>
<includes>
<include>breeze.linalg.**</include>
</includes>
</relocation>
I don't think that is the right solution, but excluding breeze is not sufficient since when you run with spark-assembly
on the class path it is included there. I tried a variety of userClassPathFirst parameters available but none solved the issue.
I think we can just move to Spark 2.0 now though?
Weird, I tried exactly that locally and wasn't seeing it work, but I'm sure I was just checking it wrong, it was late last night.
AFAICT Spark 2.0.0 still uses Breeze 0.11.2; they upgraded breeze on July 19 right around when the 2.0 branch seems to have been cut, but I guess it didn't make it?
Either way, I think we should just fix it now and not couple it to a Spark 2.0 upgrade.
I don't think that is the right solution
OOC why not? This seems like exactly the case where a targeted shading is the right way to get what we want, similarly to the guava situation
OOC why not? This seems like exactly the case where a targeted shading is the right way to get what we want, similarly to the guava situation
Yea, that's true. I don't have a reason why really, just seems kludge-y.
Either way, I think we should just fix it now and not couple it to a Spark 2.0 upgrade.
Sure, I'll verify this still works on master and make a PR
Also, double-checking, it seems the above was what I tried orignally and didn't work, but the following did.
<relocation>
<pattern>breeze</pattern>
<shadedPattern>org.hammerlab.breeze</shadedPattern>
<includes>
<include>breeze.**</include>
</includes>
</relocation>
Yea I just noticed that we need some breeze.math
things shaded in addition to breeze.linalg
.
Also my previous approach wasn't working because I had a typo in the breeze line in:
<artifactSet>
<includes>
<include>org.hammerlab.guacamole:*</include>
<include>com.google.guava:*</include>
<include>org.scalanlp:breeze_${scala.version.prefix}</include>
</includes>
</artifactSet>
I'm trying a version with a second breeze relocation
just for breeze.math
though it doesn't seem to have changed what ends up in the guac JAR…
Yea, that's true. I don't have a reason why really, just seems kludge-y.
Agreed, it's annoying to have to deal with, but there isn't really another option for situations like this, afaik!
Sure, I'll verify this still works on master and make a PR
Sounds great, thanks.
Locally, I'm up to my 3rd breeze-subpkg relocation
, numerics
… seems like shading all of breeze may be the way to go.
Also re: my
it doesn't seem to have changed what ends up in the guac JAR…
turns out I was checking by just counting hits for "breeze" in a jar tf
, but I should have been grepping for "hammerlab/breeze" because all of breeze is in there either way, TIL.
Some parts of Breeze need to be shaded in order for Guacamole to run via
spark-submit
; mllib depends on breeze 0.11.2 and I think that ends up on the classpath ahead of our 0.12 dependency when we usespark-{submit,shell}
.Example crash, from just after #571 was merged:
I poked at how to do the shading a bit just now but couldn't get it working.