Github user srowen commented on the issue:
    Yeah 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 or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to