Github user srowen commented on the issue:
Yeah https://github.com/apache/spark/pull/14981#issuecomment-247789298 is
certainly the argument against including them, that's clear.
But I also outlined the argument 'for': you could also view the publishing
of Maven artifacts as just the 'instructions on how to obtain and install the
non-included work'. On its face, it seems to be about something else; it seems
to mean that ASF projects may simply provide instructions about getting the
Kinesis client. But how Spark supposed to optionally work with Kinesis client
with zero integration code? This is only true in quite rare cases (like,
netlib-java!). This doesn't sound like the intent, to forbid any integration
code in a project, as long as the integration itself is optional. And it is.
I want to be pretty sure there's _no_ decent argument for keeping the
artifacts, because stopping publishing them affects users.
The ongoing thread has no authoritative outcome. The 'safe' thing to do
from a policy perspective is not to distribute these artifacts, I suppose. I
admit, I myself am neutral, because I have no particular interest in these
integrations. However, I also don't see anything here that suggests binary is
different from source. Source is actually the authoritative artifact from the
ASF, so "only" publishing source doesn't change things. That is, we'd be
arguing that the whole module has to be deleted.
If it must be, so be it, but I don't yet see it must be.
What we do know is that the kinesis assembly has to go. If we're about to
release 2.0.1, we must do that. I suggest we not block 2.0.1 on further removal
of artifacts unless an authoritative position emerges before its release that
says they must go.
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 infrastruct...@apache.org or file a JIRA ticket
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org