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 code
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, M
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 want to keep a
separa
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 dow
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 t
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 wrote:
>> Hello all,
>>
>> I'd l
+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 Spark. For reference, here
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é mailto:j...@nanthrax.net>> wrote:
Thanks for the update Kosta
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 Sakellis 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 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 seriousl
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: https://github.com/spar
11 matches
Mail list logo
