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" <amos.elb...@gmail.com> 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 <jeffrey.steinm...@gmail.com> >> 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" <jeffrey.steinm...@gmail.com> 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" <g...@git.apache.org> 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 infrastruct...@apache.org or file a JIRA ticket >>>> with INFRA. >>>> --- >>
