[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
GitHub user Leemoonsoo opened a pull request:

    https://github.com/apache/incubator-zeppelin/pull/815

    [WIP] Two SparkR implementation conflict in master branch

    ### What is this PR for?
    Recently #208 and #702 are merged into master branch.
    They passed the CI test individually, but failing after both merged.
   
   
    * zeppelin-web build error
    ```
    [ERROR] npm ERR! registry error parsing json
    [ERROR] npm http 200 https://registry.npmjs.org/bower/1.7.2
    [ERROR] npm ERR! SyntaxError: Unexpected token 
    [ERROR] npm ERR! ��Y[o�6�+��6��ulE���
    [ERROR] npm ERR! �{h�� C�ˑ�L=RJ��o�9b�4����W4� ["��wn���E���2C�ϕn���U`��a�
    [ERROR] npm ERR! G�p^@��$e�Ley,��IU�"/K�,qr�[8�F���^���p������Z�����=x?�}��{W�+���ܳЀ쵱���}
    ```
   
    * 'SparkRInterpreter.java' and 'RRepl.java' uses the same interpreter name. 'spark.r'.
    That conflicts and make https://github.com/apache/incubator-zeppelin/blob/master/zeppelin-server/src/test/java/org/apache/zeppelin/rest/ZeppelinSparkClusterTest.java#L87 fails.
   
    * R.md and r.md both exists under same directory. That confuses git client.
   
    ### What type of PR is it?
    Hot Fix
   
    ### Todos
    * [x] - Merge R.md and r.md
    * [x] - Fix zeppelin-web build error
    * [ ] - Fix interpreter name conflict
   
    ### What is the Jira issue?
   
    ### How should this be tested?
   
    ### Screenshots (if appropriate)
   
    ### Questions:
    * Does the licenses files need update? no
    * Is there breaking changes for older versions? no
    * Does this needs documentation? no


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/Leemoonsoo/incubator-zeppelin r_hotfix

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-zeppelin/pull/815.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #815
   
----
commit 6854ac7e0a5adf592ec801dd8ef033d04f53c537
Author: Lee moon soo <[hidden email]>
Date:   2016-04-05T09:01:49Z

    R.md -> r.md

commit 9baf57b68c702e87845158503d8ace749937dbcc
Author: Lee moon soo <[hidden email]>
Date:   2016-04-05T09:47:42Z

    Change node and npm version

----


---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
Github user bzz commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205770225
 
    @Leemoonsoo thank you for taking care of CI failure on short notice!


---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user bzz commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205831036
 
    Looks great to me, let's merge asap as a hotfix


---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user elbamos commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205889050
 
    Is there a proposal for what Eric and I should do about the name conflict?
   
    > On Apr 5, 2016, at 10:21 AM, Alexander <[hidden email]> wrote:
    >
    > Looks great to me, let's merge asap as a hotfix
    >
    > —
    > You are receiving this because you are subscribed to this thread.
    > Reply to this email directly or view it on GitHub
    >



---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user Leemoonsoo commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928193
 
    I'm merging it as a hotfix.



---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user Leemoonsoo commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
 
   
    Regarding, name conflict, i can come up with some options.
   
    a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
    And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
   
    b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
   
    c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
    And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
   
   
    Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
   
    What do you think?


---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user asfgit closed the pull request at:

    https://github.com/apache/incubator-zeppelin/pull/815


---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

[GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

yx91490
In reply to this post by yx91490
Github user elbamos commented on the pull request:

    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205943423
 
    My preference is b because it imposes the least burden on users.
   
    I think most R users will want spark integration, and I think we disagree about which interpreters provide closer spark integration.
   
    > On Apr 5, 2016, at 2:19 PM, Lee moon soo <[hidden email]> wrote:
    >
    > Regarding, name conflict, i can come up with some options.
    >
    > a. Keep the same name 'spark.r' for both SparkRInterpreter and RRepl.
    > And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using zeppelin.interpreters property in conf/zeppelin-site.xml
    >
    > b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
    >
    > c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
    > And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what ZEPPELIN-502 trying to do for python
    >
    > Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
    >
    > What do you think?
    >
    > —
    > You are receiving this because you commented.
    > Reply to this email directly or view it on GitHub
    >



---
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 [hidden email] or file a JIRA ticket
with INFRA.
---
Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Jeff Steinmetz
In reply to this post by yx91490
I actually was thinking about an idea similar to option C before this topic came up.
208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.

B also looks like an decent option as well, but my preference is C.






On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:

>Github user Leemoonsoo commented on the pull request:
>
>    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>  
>    
>    Regarding, name conflict, i can come up with some options.
>    
>    a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>    And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>    
>    b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>    
>    c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>    And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>    
>    
>    Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>    
>    What do you think?
>
>
>---
>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 [hidden email] or file a JIRA ticket
>with INFRA.
>---

Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Jeff Steinmetz
Did the -Pr profile get set up to work with distribution via -Pbuild-distr?
If not, it can’t be used yet in its current form (unless this was taken care of and I missed the follow up PR)
It this was already implemented - disregard this comment.






On 4/5/16, 11:58 AM, "Jeff Steinmetz" <[hidden email]> wrote:

>I actually was thinking about an idea similar to option C before this topic came up.
>208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
>
>B also looks like an decent option as well, but my preference is C.
>
>
>
>
>
>
>On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:
>
>>Github user Leemoonsoo commented on the pull request:
>>
>>    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>  
>>    
>>    Regarding, name conflict, i can come up with some options.
>>    
>>    a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>    And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>    
>>    b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>>    
>>    c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>>    And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>>    
>>    
>>    Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>>    
>>    What do you think?
>>
>>
>>---
>>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 [hidden email] or file a JIRA ticket
>>with INFRA.
>>---
>

Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Amos B. Elberg
Build-distr wasn't resolved but I don't get what you mean about it can't be used - the source code is our release. Build-distr is just the "convenience" binary, no?

> On Apr 5, 2016, at 4:11 PM, Jeff Steinmetz <[hidden email]> wrote:
>
> Did the -Pr profile get set up to work with distribution via -Pbuild-distr?
> If not, it can’t be used yet in its current form (unless this was taken care of and I missed the follow up PR)
> It this was already implemented - disregard this comment.
>
>
>
>
>
>
>> On 4/5/16, 11:58 AM, "Jeff Steinmetz" <[hidden email]> wrote:
>>
>> I actually was thinking about an idea similar to option C before this topic came up.
>> 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
>>
>> B also looks like an decent option as well, but my preference is C.
>>
>>
>>
>>
>>
>>
>>> On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:
>>>
>>> Github user Leemoonsoo commented on the pull request:
>>>
>>>   https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>>
>>>
>>>   Regarding, name conflict, i can come up with some options.
>>>
>>>   a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>>   And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>>
>>>   b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>>>
>>>   c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>>>   And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>>>
>>>
>>>   Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>>>
>>>   What do you think?
>>>
>>>
>>> ---
>>> 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 [hidden email] or file a JIRA ticket
>>> with INFRA.
>>> ---
>
Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Jeff Steinmetz
correct - it can be used from source as you pointed out (for a developer friendly audience ok with the use Maven).
Mainly referring to the use of build-distr for compressed binaries for easier distribution.
i.e. for devops/sysops that build from source and want to release using their preferred IT/Deployment automation tool using a single compressed archive.

j



On 4/5/16, 3:18 PM, "Amos B. Elberg" <[hidden email]> wrote:

>Build-distr wasn't resolved but I don't get what you mean about it can't be used - the source code is our release. Build-distr is just the "convenience" binary, no?
>
>> On Apr 5, 2016, at 4:11 PM, Jeff Steinmetz <[hidden email]> wrote:
>>
>> Did the -Pr profile get set up to work with distribution via -Pbuild-distr?
>> If not, it can’t be used yet in its current form (unless this was taken care of and I missed the follow up PR)
>> It this was already implemented - disregard this comment.
>>
>>
>>
>>
>>
>>
>>> On 4/5/16, 11:58 AM, "Jeff Steinmetz" <[hidden email]> wrote:
>>>
>>> I actually was thinking about an idea similar to option C before this topic came up.
>>> 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
>>>
>>> B also looks like an decent option as well, but my preference is C.
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:
>>>>
>>>> Github user Leemoonsoo commented on the pull request:
>>>>
>>>>   https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>>>
>>>>
>>>>   Regarding, name conflict, i can come up with some options.
>>>>
>>>>   a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>>>   And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>>>
>>>>   b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>>>>
>>>>   c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>>>>   And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>>>>
>>>>
>>>>   Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>>>>
>>>>   What do you think?
>>>>
>>>>
>>>> ---
>>>> 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 [hidden email] or file a JIRA ticket
>>>> with INFRA.
>>>> ---
>>

Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Eric Charles
In reply to this post by Jeff Steinmetz
C) sounds also logical to me. It follows closer the implementation.

On 05/04/16 20:58, Jeff Steinmetz wrote:

> I actually was thinking about an idea similar to option C before this topic came up.
> 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
>
> B also looks like an decent option as well, but my preference is C.
>
>
>
>
>
>
> On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:
>
>> Github user Leemoonsoo commented on the pull request:
>>
>>     https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>
>>
>>     Regarding, name conflict, i can come up with some options.
>>
>>     a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>     And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>
>>     b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>>
>>     c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>>     And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>>
>>
>>     Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>>
>>     What do you think?
>>
>>
>> ---
>> 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 [hidden email] or file a JIRA ticket
>> with INFRA.
>> ---
>
Reply | Threaded
Open this post in threaded view
|

Re: [GitHub] incubator-zeppelin pull request: [WIP] Two SparkR implementation c...

Amos B. Elberg
If the interpreters get moved out of the spark interpretergroup, they won't be able to access spark.

> On Apr 6, 2016, at 2:49 AM, Eric Charles <[hidden email]> wrote:
>
> C) sounds also logical to me. It follows closer the implementation.
>
>> On 05/04/16 20:58, Jeff Steinmetz wrote:
>> I actually was thinking about an idea similar to option C before this topic came up.
>> 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
>>
>> B also looks like an decent option as well, but my preference is C.
>>
>>
>>
>>
>>
>>
>>> On 4/5/16, 11:18 AM, "Leemoonsoo" <[hidden email]> wrote:
>>>
>>> Github user Leemoonsoo commented on the pull request:
>>>
>>>    https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>>
>>>
>>>    Regarding, name conflict, i can come up with some options.
>>>
>>>    a. Keep the same name 'spark.r' for both [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) and [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>>    And let user select it in build time using maven profile, -Pr for RRepl, -Psparkr for SparkRInterpreter, or select it in a runtime using `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>>
>>>    b. Change SparkRInterpreter name to 'spark.sparkr', similar to PySparkInterpreter uses the name 'spark.pyspark'
>>>
>>>    c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', r.knitr'.
>>>    And make RRepl and KnitR more like generic R support rather than SparkR support. Similar to what [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to do for python
>>>
>>>
>>>    Personally, i'm good with all three options and prefer c) as a long term plan, while my guess is many R users will use r without sparkr integration.
>>>
>>>    What do you think?
>>>
>>>
>>> ---
>>> 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 [hidden email] or file a JIRA ticket
>>> with INFRA.
>>> ---
>>