Re: SPARK-13843 Next steps

while sonatype are utterly strict about the org.apache namespace (it guarantees that all such artifacts have come through the ASF release process, ideally including code-signing), nobody checks the org.apache internals, or worries too much about them. Note that spark itself has some bits of

Re: SPARK-13843 Next steps

I tend to agree. If it's going to present a significant technical hurdle and the software is clearly non ASF like via a different artifact, there's a decent argument the namespace should stay. The artifact has to change though and that is what David was referring to in his other message. On Mon,

Re: SPARK-13843 Next steps

On Mon, Mar 28, 2016 at 8:33 AM, Cody Koeninger wrote: > There are compatibility problems with the java namespace changing > (e.g. access to private[spark]) I think it would be fine to keep the package names for backwards compatibility, but I think if these external projects

Re: SPARK-13843 Next steps

I really think the only thing that should have to change is the maven group and identifier, not the java namespace. There are compatibility problems with the java namespace changing (e.g. access to private[spark]), and I don't think that someone who takes the time to change their build file to

Re: SPARK-13843 Next steps

Looks like this is done; docs have been moved, flume is back in, etc. For the moment Kafka streaming is still in the project and I know there's still discussion about how to manage multiple versions within the project. One other thing we need to finish up is stuff like the namespace of the code

Re: SPARK-13843 Next steps

I'm in favor of everything in /extras and /external being removed, but I'm more in favor of making a decision and moving on. On Tue, Mar 22, 2016 at 12:20 PM, Marcelo Vanzin wrote: > +1 for getting flume back. > > On Tue, Mar 22, 2016 at 12:27 AM, Kostas Sakellis

Re: SPARK-13843 Next steps

+1 for getting flume back. On Tue, Mar 22, 2016 at 12:27 AM, Kostas Sakellis wrote: > Hello all, > > I'd like to close out the discussion on SPARK-13843 by getting a poll from > the community on which components we should seriously reconsider re-adding > back to Apache

Re: SPARK-13843 Next steps

OK, so kafka, kinesis and flume will stay in Spark. Thanks, Regards JB On 03/22/2016 08:30 AM, Reynold Xin wrote: Kinesis is still in it. I think it's OK to add Flume back. On Tue, Mar 22, 2016 at 12:29 AM, Jean-Baptiste Onofré > wrote: Thanks

Re: SPARK-13843 Next steps

Kinesis is still in it. I think it's OK to add Flume back. On Tue, Mar 22, 2016 at 12:29 AM, Jean-Baptiste Onofré wrote: > Thanks for the update Kostas, > > for now, kafka stays in Spark and Kinesis will be removed, right ? > > Regards > JB > > On 03/22/2016 08:27 AM, Kostas

Re: SPARK-13843 Next steps

Thanks for the update Kostas, for now, kafka stays in Spark and Kinesis will be removed, right ? Regards JB On 03/22/2016 08:27 AM, Kostas Sakellis wrote: Hello all, I'd like to close out the discussion on SPARK-13843 by getting a poll from the community on which components we should

SPARK-13843 Next steps

Hello all, I'd like to close out the discussion on SPARK-13843 by getting a poll from the community on which components we should seriously reconsider re-adding back to Apache Spark. For reference, here are the modules that were removed as part of SPARK-13843 and pushed to: