> > > > > > >
> > > > > > > > > > > +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 Dril
gt; > > > > > However, I would suggest that review may be needed. As each
> > > test
> > > > > and
> > > > > > > > > interpreter adds Zeppelin code, it also adds to the
> > > distributable
> > > >
in size. Is the
> > > goal
> > > > to
> > > > > > > > provide a completely standalone Zeppelin with all the
> > > interpreters
> > > > > and
> > > > > >
gt; > > > > > included
> > > > > > > in a standalone distribution.
> > > > > > >
> > > > > > > paul
> > > > > > >
> > > > > > > On Wed, Jul 22, 2015 at 7:52 AM, IT CTO >
> > wrote:
&
t; > > > 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
> >
he
> 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 wit
ake the intepreters system modular to decouple
> souce
> > > > code,
> > > > > > the process of activating an interpreter should be flexible and
> > easy
> > > to
> > > > > > use.
> > > > > >
> > > > >
sy
> > 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
> > &g
sking 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,
> in
; > >
> > > 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, wrote:
> > >
> > > > +1 what tog says
> > > >
> > >
ncorrect
> > 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, wrote:
> >
> > > +1 what to
.)
>
> 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, wrote:
>
> > +1 what tog says
> >
> >
> >
> >
> > From: tog
> >
> >
gt;
>
>
> From: tog
>
> Sent: Wednesday, July 22, 12:22 AM
>
> Subject: Interpreter with no test.
>
> To: dev@zeppelin.incubator.apache.org
>
>
>
> +1
>
> This seems to be a recurrent topic ;-)
>
>
> It has to be decided what are the core interpre
+1 what tog says
From: tog
Sent: Wednesday, July 22, 12:22 AM
Subject: Interpreter with no test.
To: dev@zeppelin.incubator.apache.org
+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
+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 p
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 inte
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 wrote:
> H
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, keepin
19 matches
Mail list logo
