Github user srowen commented on the pull request:
https://github.com/apache/spark/pull/1813#issuecomment-51647806
@vanzin Yes there's no problem with publishing artifacts containing copies
of other artifacts as far as Maven Central is concerned. It's just icky for
downstream consumers. I think the non-assembly artifacts should be the
'pristine' raw ingredients and assemblies can be crazy remixes.
I can see the argument for provided. It has the pros and cons you mention.
It's a moot point for people that use Spark as `provided`, which is what
they're supposed to do. So, meh. Just drop a comment in the POM to explain the
scope.
I had understood that the goal was to alter the Spark assembly in some way,
such that with some certain footwork in the Hive on Spark build, the Hive on
Spark assembly would work with the Spark assembly as deployed on people's
clusters. That's mostly about getting Guava out of the way.
I don't think this entails making anyone depend on a shaded anything in
Maven. I think that's avoidable and undesirable. So I think we are all
basically agreeing on that? So to be clear, Spark continues to express a
dependency on Guava in its POM. It must. The shading affects deployed
assemblies.
The only delta with what @pwendell suggests seems to be shading in Guava's
Optional rather than keeping a source copy. But that seems fine.
---
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]
