Github user vanzin commented on the pull request:
https://github.com/apache/spark/pull/3658#issuecomment-71545834
> Does this suggest any limits on how many overall dependencies we can
shade in Spark longer term (i.e. in addition to guava)?
If we choose relocation as the official way of fixing potential library
version conflicts, we'll end up with a growing spark-core. I don't think
there's a limit to how many classes you can add (SPARK-1520 notwithstanding),
but it doesn't look very pretty, I agree. I did this mainly to fix some issues
with the current way Guava is shaded, though, not as a blueprint for how to fix
dependency issues going forward.
(It also can confuse certain IDEs that automatically add import
statements...)
> Why not just have the shaded guava in the little assembly jar we create
for YARN?
That's definitely an option. Should be pretty easy to do if that's the
preferred way, but I remember that it was a conscious choice to depend on the
Yarn-provided Guava.
> would we still publish the network modules then?
Do they provide any public APIs? If they do, then yes. Otherwise, there
would be no need to publish them.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
