+1 I agree with tog ... the core interpreters should be those that can complete all the tests and provide the functionality as well. Spark local being the best example. The Apache Drill interpreter I wrote would need a single node Drill installation in order to provide the same testing capability. I am working to provide this.
However, I would suggest that review may be needed. As each test and interpreter adds Zeppelin code, it also adds to the distributable as well. Currently, the distributable is around ~500MB in size. Is the goal to provide a completely standalone Zeppelin with all the interpreters and environments included? Or is the goal to provide a front end to those environments? Maybe that's the decision: which environments and interpreters are included in a standalone distribution. paul On Wed, Jul 22, 2015 at 7:52 AM, IT CTO <[email protected]> wrote: > I think that we can have the interpreters add in the build system using > compilation parameters (e.g. same as the list in the zeppelin-env.xml that > way the basic build builds only the core interpreters and the user can > easily interperters to the build process. > With regard to a release, this can be just as adding the jar and the config > or just the jar with auto-discovery > Eran > > On Wed, Jul 22, 2015 at 1:40 PM DuyHai Doan <[email protected]> wrote: > > > If we want to make the intepreters system modular to decouple souce code, > > the process of activating an interpreter should be flexible and easy to > > use. > > > > Asking end-users to make a custom build is not a viable strategy. > Recently > > I've seen some people trying to make a custom build of Zeppelin and > facing > > a lot of issues (incorrect Maven version, no Bower installed, incorrect > > repository policies settings for Maven etc ...) > > > > Ideally, activating an interpreter should be as simple as dropping a jar > > into the lib directory > > > > On Wed, Jul 22, 2015 at 12:28 PM, <[email protected]> wrote: > > > > > +1 what tog says > > > > > > > > > > > > > > > From: tog > > > > > > Sent: Wednesday, July 22, 12:22 AM > > > > > > Subject: Interpreter with no test. > > > > > > To: [email protected] > > > > > > > > > > > > +1 > > > > > > This seems to be a recurrent topic ;-) > > > > > > > > > It has to be decided what are the core interpreters the Zeppelin want > to > > > > > > support - then I would believe you can have a wiki/webpage dedicated to > > > > > > listing all interpreters that are known to be working with Zeppelin. > You > > > > > > may even consider having recommended plugins and/or ranking in case 2 > > > > > > plugins are doing the same job. Grails (but it is probably not the only > > > > > > one) is implementing this (see https://grails.org/plugins/) > > > > > > > > > In order to keep Zeppelin low in term of footprint - the core commiters > > can > > > > > > even decide to support some of those plugins (shell for example) > > > > > > At one end of the spectrum you could imagine Zeppelin without any > > > > > > interpreters and at the other end Zeppelin with all known plugins - the > > > > > > truth is probably in the middle. > > > > > > > > > > > > On Wednesday, July 22, 2015, Anthony Corbacho < > > [email protected] > > > > > > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > IT CTO is right, right now, zeppelin merge every interpreter in the > > code > > > > > > > base and its mean that we (committer) have to take care of build > > falling > > > or > > > > > > > questions for those interpreters. and personally i have no experience > > in > > > > > > > presto, cassandra etcetc. > > > > > > > > > > > > > > I think, It can be interesting to detach interpreters from zeppelin > > code > > > > > > > base and create a sortof plug'n'play module where the users can plug > > the > > > > > > > interpreter he wants to use. > > > > > > > > > > > > > > With this approach, we can keep zeppelin code base smaller (we > provide > > > the > > > > > > > core + maybe some interpreters (spark, md, shell) as default). and > the > > > > > > > community can build and manage other interpreters (i assume if they > > build > > > > > > > it they have experiences and probably can answer questions). > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > On Wed, Jul 22, 2015 at 2:34 PM, IT CTO <[email protected]> wrote: > > > > > > > > > > > > > > > I think the question is what\who is going to fix issues in these > > > > > > > > Interpreters if something fails? > > > > > > > > I am guessing that if one uses these interpreters and approach the > > > > > > > > community with questions then we might not have the right support > for > > > > > > > him. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 22, 2015 at 8:04 AM moon soo Lee <[email protected]> > > wrote: > > > > > > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > > > > > There're some open pullrequests with complete interpreter > > > > > > > implementation > > > > > > > > > but no test (eg. > > > https://github.com/apache/incubator-zeppelin/pull/110 > > > > > > > , > > > > > > > > > https://github.com/apache/incubator-zeppelin/pull/68). > > > > > > > > > > > > > > > > > > Personally, I'm feeling not safe having code without test, but at > > the > > > > > > > > same > > > > > > > > > time, keeping these great contributions unmerged sounds not cool. > > > > > > > > > > > > > > > > > > I'd like to hear opinions about merging them with some mark such > as > > > > > > > > 'beta' > > > > > > > > > or 'untested', and create issue for adding test. > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > moon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net > > > > > > -- *Paul Curtis - *Senior Product Specialist - Field Enablement Team *O: *+1 203-660-0015 - *M:* +1 203-539-9705 Now Available - Free Hadoop On-Demand Training <http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available>
