[GitHub] zeppelin issue #3258: fix beam-runners-flink and zeppelin-scio scala version...

2018-12-11 Thread avnerl
Github user avnerl commented on the issue:

https://github.com/apache/zeppelin/pull/3258
  
> also we could upgrade beam interpreter to "require" beam 2.3 also (so it 
does build with scala-2.11)

this's what i did in: 
https://github.com/apache/zeppelin/pull/3258/commits/ffca03cbd4c9d6cb756eef1b21a1319f8d8c5759

do you have a better approach?


---


[GitHub] zeppelin issue #3258: fix beam-runners-flink and zeppelin-scio scala version...

2018-12-11 Thread felixcheung
Github user felixcheung commented on the issue:

https://github.com/apache/zeppelin/pull/3258
  
also we could upgrade beam interpreter to "require" beam 2.3 also (so it 
does build with scala-2.11)


---


[GitHub] zeppelin issue #3258: fix beam-runners-flink and zeppelin-scio scala version...

2018-12-11 Thread felixcheung
Github user felixcheung commented on the issue:

https://github.com/apache/zeppelin/pull/3258
  
what about we don't build beam and scio if scala-2.11?


---


Re: [DISCUSS] Make interpreters' repository

2018-12-11 Thread Jongyoul Lee
And for testing Z as well, we don't have to build Spark Interpreter again
for integration tests. and even, we don't have to build zeppelin server and
web for integration test for spark. We just use components built. I believe
it makes our CI as well faster.

On Wed, Dec 12, 2018 at 3:29 PM Jongyoul Lee  wrote:

> Yes, right. BTW, I think we need to make dependencies clearly between
> zeppelin-server and interpreters, and even among interpreters. Some
> versions properties are used in zeppelin-server and interpreters, but no
> one has any clear view for them. So I thought it would be a change when we
> divide repositories. The second one is about building and compiling. We
> don't have to build Zeppelin fully when building some components. We also
> can do it with custom build options including '-pl !...'. I don't think
> it's good and there's no reason to keep this kind of inconvenience. What do
> you think?
>
> Regards,
> JL
>
> On Wed, Dec 12, 2018 at 3:08 PM Jeff Zhang  wrote:
>
>> Hi Jongyoul,
>>
>> Thanks for bring this up. I don't understand how different repo will help
>> here, but I thought about moving interpreters out of zeppelin for a long
>> time, but don't have bandwidth for it. The release cycle of zeppelin core
>> component (zeppelin-zengine, zeppelin-server) should not block the release
>> of interpreter component (unless they depends on some features of
>> zeppelin-zengine, zeppelin-server).
>>
>>
>> Jongyoul Lee  于2018年12月12日周三 上午10:38写道:
>>
>> > Hi, dev and committers,
>> >
>> > Currently, I'm seeing the repositories of another apache projects. They
>> > have some several repositories with different purposes. I'd like to
>> suggest
>> > you that we divide repositories between zeppelin-server and others.
>> >
>> > This will help you develop zeppelin-server without interfering from
>> other
>> > components and its dependencies. Even, in the case of interpreters, It
>> will
>> > provide more independent environments for developing interpreters
>> > themselves. Currently, we had a lot of dependencies and various versions
>> > for each interpreter.
>> >
>> > WDYT?
>> >
>> > Regards,
>> > JL
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>>
>>
>> --
>> Best Regards
>>
>> Jeff Zhang
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


Re: [DISCUSS] Make interpreters' repository

2018-12-11 Thread Jongyoul Lee
Yes, right. BTW, I think we need to make dependencies clearly between
zeppelin-server and interpreters, and even among interpreters. Some
versions properties are used in zeppelin-server and interpreters, but no
one has any clear view for them. So I thought it would be a change when we
divide repositories. The second one is about building and compiling. We
don't have to build Zeppelin fully when building some components. We also
can do it with custom build options including '-pl !...'. I don't think
it's good and there's no reason to keep this kind of inconvenience. What do
you think?

Regards,
JL

On Wed, Dec 12, 2018 at 3:08 PM Jeff Zhang  wrote:

> Hi Jongyoul,
>
> Thanks for bring this up. I don't understand how different repo will help
> here, but I thought about moving interpreters out of zeppelin for a long
> time, but don't have bandwidth for it. The release cycle of zeppelin core
> component (zeppelin-zengine, zeppelin-server) should not block the release
> of interpreter component (unless they depends on some features of
> zeppelin-zengine, zeppelin-server).
>
>
> Jongyoul Lee  于2018年12月12日周三 上午10:38写道:
>
> > Hi, dev and committers,
> >
> > Currently, I'm seeing the repositories of another apache projects. They
> > have some several repositories with different purposes. I'd like to
> suggest
> > you that we divide repositories between zeppelin-server and others.
> >
> > This will help you develop zeppelin-server without interfering from other
> > components and its dependencies. Even, in the case of interpreters, It
> will
> > provide more independent environments for developing interpreters
> > themselves. Currently, we had a lot of dependencies and various versions
> > for each interpreter.
> >
> > WDYT?
> >
> > Regards,
> > JL
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>
>
> --
> Best Regards
>
> Jeff Zhang
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


Re: [DISCUSS] Make interpreters' repository

2018-12-11 Thread Jeff Zhang
Hi Jongyoul,

Thanks for bring this up. I don't understand how different repo will help
here, but I thought about moving interpreters out of zeppelin for a long
time, but don't have bandwidth for it. The release cycle of zeppelin core
component (zeppelin-zengine, zeppelin-server) should not block the release
of interpreter component (unless they depends on some features of
zeppelin-zengine, zeppelin-server).


Jongyoul Lee  于2018年12月12日周三 上午10:38写道:

> Hi, dev and committers,
>
> Currently, I'm seeing the repositories of another apache projects. They
> have some several repositories with different purposes. I'd like to suggest
> you that we divide repositories between zeppelin-server and others.
>
> This will help you develop zeppelin-server without interfering from other
> components and its dependencies. Even, in the case of interpreters, It will
> provide more independent environments for developing interpreters
> themselves. Currently, we had a lot of dependencies and various versions
> for each interpreter.
>
> WDYT?
>
> Regards,
> JL
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>


-- 
Best Regards

Jeff Zhang


[GitHub] zeppelin issue #3259: Upgrade Jetty version to the latest version - 9.4.14.v...

2018-12-11 Thread jongyoul
Github user jongyoul commented on the issue:

https://github.com/apache/zeppelin/pull/3259
  
We had two different CI. one is for appveyor which actually doesn't test 
anything. another one is travis. Could you please check your travis? I don't 
think you set the CI correctly. Please see 
https://travis-ci.org/fred521/zeppelin/


---


[jira] [Created] (ZEPPELIN-3904) R Interpreter does not work for All Spark Versions

2018-12-11 Thread Mark Bidewell (JIRA)
Mark Bidewell created ZEPPELIN-3904:
---

 Summary: R Interpreter does not work for All Spark Versions
 Key: ZEPPELIN-3904
 URL: https://issues.apache.org/jira/browse/ZEPPELIN-3904
 Project: Zeppelin
  Issue Type: Bug
  Components: r-interpreter
Affects Versions: 0.8.0
Reporter: Mark Bidewell


When the R Interpreter tries . isSecretSocketSupported(), this check only 
supports 2.3.1 and above whereas the secret socket change was made in 2.1.  
This causes the R Interpreter to fail for the Spark 2.2.x series.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] zeppelin issue #3259: Upgrade Jetty version to the latest version - 9.4.14.v...

2018-12-11 Thread fred521
Github user fred521 commented on the issue:

https://github.com/apache/zeppelin/pull/3259
  
here is the link


https://ci.appveyor.com/project/ApacheSoftwareFoundation/zeppelin/builds/20912238

On Tue, Dec 11, 2018 at 6:37 PM Fred  wrote:

> Yes, It passes all the tests
>
> On Tue, Dec 11, 2018 at 6:31 PM Jongyoul Lee 
> wrote:
>
>> Could you please check your CI? I think this should pass all of our tests
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> ,
>> or mute the thread
>> 

>> .
>>
>



---


[DISCUSS] Make interpreters' repository

2018-12-11 Thread Jongyoul Lee
Hi, dev and committers,

Currently, I'm seeing the repositories of another apache projects. They
have some several repositories with different purposes. I'd like to suggest
you that we divide repositories between zeppelin-server and others.

This will help you develop zeppelin-server without interfering from other
components and its dependencies. Even, in the case of interpreters, It will
provide more independent environments for developing interpreters
themselves. Currently, we had a lot of dependencies and various versions
for each interpreter.

WDYT?

Regards,
JL

-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


[GitHub] zeppelin issue #3259: Upgrade Jetty version to the latest version - 9.4.14.v...

2018-12-11 Thread fred521
Github user fred521 commented on the issue:

https://github.com/apache/zeppelin/pull/3259
  
Yes, It passes all the tests

On Tue, Dec 11, 2018 at 6:31 PM Jongyoul Lee 
wrote:

> Could you please check your CI? I think this should pass all of our tests
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> , or 
mute
> the thread
> 

> .
>



---


[GitHub] zeppelin issue #3259: Upgrade Jetty version to the latest version - 9.4.14.v...

2018-12-11 Thread jongyoul
Github user jongyoul commented on the issue:

https://github.com/apache/zeppelin/pull/3259
  
Could you please check your CI? I think this should pass all of our tests


---


[GitHub] zeppelin issue #3253: [ZEPPELIN-3551] Upgrade Scala to 2.11.12

2018-12-11 Thread HyukjinKwon
Github user HyukjinKwon commented on the issue:

https://github.com/apache/zeppelin/pull/3253
  
I'm not aware of release plan in Zeppelin since I'm just one of 
contributors. For the current status, the Spark should be downgraded as far as 
I can tell.


---


[DISCUSS] Moving to gitbox

2018-12-11 Thread Jongyoul Lee
Hi, devs,

I'd like to make a consensus to move our repository from git-wip to gitbox.

Please give your opinions with replies from this email.

Thanks in advance,
JL

-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


[GitHub] zeppelin issue #3253: [ZEPPELIN-3551] Upgrade Scala to 2.11.12

2018-12-11 Thread HyukjinKwon
Github user HyukjinKwon commented on the issue:

https://github.com/apache/zeppelin/pull/3253
  
Spark 2.4 support was added at 
https://github.com/apache/zeppelin/pull/3206, which exactly addresses the issue 
you faced. This will be available in new release of Zeppelin.


---


[GitHub] zeppelin issue #3253: [ZEPPELIN-3551] Upgrade Scala to 2.11.12

2018-12-11 Thread GezimSejdiu
Github user GezimSejdiu commented on the issue:

https://github.com/apache/zeppelin/pull/3253
  
Hi @HyukjinKwon ,
any news about this PR? Does it support Spark 2.4.0 (Scala 2.11.x) 
interpreter already? I just created a new branch which builds a [customized 
zeppelin 
docker](https://github.com/big-data-europe/docker-zeppelin/tree/0.0.1-zeppelin-0.8.0-hadoop-2.8.0-spark-2.4.0)
 based on [BDE spark docker](https://github.com/big-data-europe/docker-spark) 
and while testing it on [SANSA](https://github.com/SANSA-Stack) via 
[SANSA-Notebooks](https://github.com/SANSA-Stack/SANSA-Notebooks), found out 
that it does not work with Spark 2.4.0 :(. (see the stack trace below) : 
```shell
java.lang.NoSuchMethodException: 
scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$loopPostInit()
at java.lang.Class.getMethod(Class.java:1786)
at 
org.apache.zeppelin.spark.BaseSparkScalaInterpreter.callMethod(BaseSparkScalaInterpreter.scala:268)
at 
org.apache.zeppelin.spark.BaseSparkScalaInterpreter.callMethod(BaseSparkScalaInterpreter.scala:262)
at 
org.apache.zeppelin.spark.SparkScala211Interpreter.open(SparkScala211Interpreter.scala:84)
at 
org.apache.zeppelin.spark.NewSparkInterpreter.open(NewSparkInterpreter.java:102)
at 
org.apache.zeppelin.spark.SparkInterpreter.open(SparkInterpreter.java:62)
at 
org.apache.zeppelin.interpreter.LazyOpenInterpreter.open(LazyOpenInterpreter.java:69)
at 
org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:617)
at org.apache.zeppelin.scheduler.Job.run(Job.java:188)
at 
org.apache.zeppelin.scheduler.FIFOScheduler$1.run(FIFOScheduler.java:140)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
```

Is there a plan to have that support soon on the new release? or we have to 
downgrade and use Spark 2.3.x instead ?

Looking forward to hearing from you.

Best regards,


---


[GitHub] zeppelin pull request #3250: [Zeppelin 3792] Zeppelin SPNEGO support

2018-12-11 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/zeppelin/pull/3250


---


Re: [DISCUSS] Fwd: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

2018-12-11 Thread Felix Cheung
Yes that’s all it takes to migrate.

(And committers to setup gitbox link)

Any more thoughts from the community?



From: Jongyoul Lee 
Sent: Tuesday, December 11, 2018 1:38 AM
To: dev
Subject: Re: [DISCUSS] Fwd: [NOTICE] Mandatory relocation of Apache git 
repositories on git-wip-us.apache.org

We could create a ticket for the infra only, correct?

On Mon, Dec 10, 2018 at 12:45 PM Jeff Zhang  wrote:

> Definitely +1 for earlier, anyone volunteer for this ?
>
>
> Jongyoul Lee  于2018年12月10日周一 上午11:34写道:
>
> > I don't think we have any special reason not to move there.
> >
> > +1 for earlier
> >
> > On Mon, Dec 10, 2018 at 3:56 AM Felix Cheung 
> > wrote:
> >
> > > Hi community,
> > >
> > > The move to gitbox is coming. This does not affect Contributors -
> mostly
> > > how PR is merged. We could choose to voluntarily move early, or wait
> till
> > > later.
> > >
> > > So to discuss, should we move early?
> > >
> > >
> > > -- Forwarded message -
> > > From: Daniel Gruno 
> > > Date: Fri, Dec 7, 2018 at 8:54 AM
> > > Subject: [NOTICE] Mandatory relocation of Apache git repositories on
> > > git-wip-us.apache.org
> > > To: us...@infra.apache.org 
> > >
> > >
> > > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
> > > DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> > >
> > > Hello Apache projects,
> > >
> > > I am writing to you because you may have git repositories on the
> > > git-wip-us server, which is slated to be decommissioned in the coming
> > > months. All repositories will be moved to the new gitbox service which
> > > includes direct write access on github as well as the standard ASF
> > > commit access via gitbox.apache.org.
> > >
> > > ## Why this move? ##
> > > The move comes as a result of retiring the git-wip service, as the
> > > hardware it runs on is longing for retirement. In lieu of this, we
> > > have decided to consolidate the two services (git-wip and gitbox), to
> > > ease the management of our repository systems and future-proof the
> > > underlying hardware. The move is fully automated, and ideally, nothing
> > > will change in your workflow other than added features and access to
> > > GitHub.
> > >
> > > ## Timeframe for relocation ##
> > > Initially, we are asking that projects voluntarily request to move
> > > their repositories to gitbox, hence this email. The voluntary
> > > timeframe is between now and January 9th 2019, during which projects
> > > are free to either move over to gitbox or stay put on git-wip. After
> > > this phase, we will be requiring the remaining projects to move within
> > > one month, after which we will move the remaining projects over.
> > >
> > > To have your project moved in this initial phase, you will need:
> > >
> > > - Consensus in the project (documented via the mailing list)
> > > - File a JIRA ticket with INFRA to voluntarily move your project repos
> > > over to gitbox (as stated, this is highly automated and will take
> > > between a minute and an hour, depending on the size and number of
> > > your repositories)
> > >
> > > To sum up the preliminary timeline;
> > >
> > > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> > > relocation
> > > - January 9th -> February 6th: Mandated (coordinated) relocation
> > > - February 7th: All remaining repositories are mass migrated.
> > >
> > > This timeline may change to accommodate various scenarios.
> > >
> > > ## Using GitHub with ASF repositories ##
> > > When your project has moved, you are free to use either the ASF
> > > repository system (gitbox.apache.org) OR GitHub for your development
> > > and code pushes. To be able to use GitHub, please follow the primer
> > > at: https://reference.apache.org/committer/github
> > >
> > >
> > > We appreciate your understanding of this issue, and hope that your
> > > project can coordinate voluntarily moving your repositories in a
> > > timely manner.
> > >
> > > All settings, such as commit mail targets, issue linking, PR
> > > notification schemes etc will automatically be migrated to gitbox as
> > > well.
> > >
> > > With regards, Daniel on behalf of ASF Infra.
> > >
> > > PS:For inquiries, please reply to us...@infra.apache.org, not your
> > > project's dev list :-).
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>
>
> --
> Best Regards
>
> Jeff Zhang
>


--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


[GitHub] zeppelin issue #3258: fix beam-runners-flink and zeppelin-scio scala version...

2018-12-11 Thread avnerl
Github user avnerl commented on the issue:

https://github.com/apache/zeppelin/pull/3258
  
do you think it's a good idea to tamper with beam version in 
`dev/change_scala_version.sh` too?
build will not pass if you do not use the `-Pscala-2.11` profile explicitly 


---


[GitHub] zeppelin issue #3258: fix beam-runners-flink and zeppelin-scio scala version...

2018-12-11 Thread avnerl
Github user avnerl commented on the issue:

https://github.com/apache/zeppelin/pull/3258
  
you are right. it didn't make sense. the reason i did this is because i 
wanted the build to pass. i remove the beam interpreter afterwards as i dint 
need it.
last 2 commits is reverting back to parameterized scala version in beam and 
introduced a new beam build profile that bump beam version to 2.3.0 when when 
building with `-Pscala-2.11`.


---


Re: [DISCUSS] Fwd: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

2018-12-11 Thread Jongyoul Lee
We could create a ticket for the infra only, correct?

On Mon, Dec 10, 2018 at 12:45 PM Jeff Zhang  wrote:

> Definitely +1 for earlier, anyone volunteer for this ?
>
>
> Jongyoul Lee  于2018年12月10日周一 上午11:34写道:
>
> > I don't think we have any special reason not to move there.
> >
> > +1 for earlier
> >
> > On Mon, Dec 10, 2018 at 3:56 AM Felix Cheung 
> > wrote:
> >
> > > Hi community,
> > >
> > > The move to gitbox is coming. This does not affect Contributors -
> mostly
> > > how PR is merged. We could choose to voluntarily move early, or wait
> till
> > > later.
> > >
> > > So to discuss, should we move early?
> > >
> > >
> > > -- Forwarded message -
> > > From: Daniel Gruno 
> > > Date: Fri, Dec 7, 2018 at 8:54 AM
> > > Subject: [NOTICE] Mandatory relocation of Apache git repositories on
> > > git-wip-us.apache.org
> > > To: us...@infra.apache.org 
> > >
> > >
> > > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
> > >   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> > >
> > > Hello Apache projects,
> > >
> > > I am writing to you because you may have git repositories on the
> > > git-wip-us server, which is slated to be decommissioned in the coming
> > > months. All repositories will be moved to the new gitbox service which
> > > includes direct write access on github as well as the standard ASF
> > > commit access via gitbox.apache.org.
> > >
> > > ## Why this move? ##
> > > The move comes as a result of retiring the git-wip service, as the
> > > hardware it runs on is longing for retirement. In lieu of this, we
> > > have decided to consolidate the two services (git-wip and gitbox), to
> > > ease the management of our repository systems and future-proof the
> > > underlying hardware. The move is fully automated, and ideally, nothing
> > > will change in your workflow other than added features and access to
> > > GitHub.
> > >
> > > ## Timeframe for relocation ##
> > > Initially, we are asking that projects voluntarily request to move
> > > their repositories to gitbox, hence this email. The voluntary
> > > timeframe is between now and January 9th 2019, during which projects
> > > are free to either move over to gitbox or stay put on git-wip. After
> > > this phase, we will be requiring the remaining projects to move within
> > > one month, after which we will move the remaining projects over.
> > >
> > > To have your project moved in this initial phase, you will need:
> > >
> > > - Consensus in the project (documented via the mailing list)
> > > - File a JIRA ticket with INFRA to voluntarily move your project repos
> > >over to gitbox (as stated, this is highly automated and will take
> > >between a minute and an hour, depending on the size and number of
> > >your repositories)
> > >
> > > To sum up the preliminary timeline;
> > >
> > > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> > >relocation
> > > - January 9th -> February 6th: Mandated (coordinated) relocation
> > > - February 7th: All remaining repositories are mass migrated.
> > >
> > > This timeline may change to accommodate various scenarios.
> > >
> > > ## Using GitHub with ASF repositories ##
> > > When your project has moved, you are free to use either the ASF
> > > repository system (gitbox.apache.org) OR GitHub for your development
> > > and code pushes. To be able to use GitHub, please follow the primer
> > > at: https://reference.apache.org/committer/github
> > >
> > >
> > > We appreciate your understanding of this issue, and hope that your
> > > project can coordinate voluntarily moving your repositories in a
> > > timely manner.
> > >
> > > All settings, such as commit mail targets, issue linking, PR
> > > notification schemes etc will automatically be migrated to gitbox as
> > > well.
> > >
> > > With regards, Daniel on behalf of ASF Infra.
> > >
> > > PS:For inquiries, please reply to us...@infra.apache.org, not your
> > > project's dev list :-).
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>
>
> --
> Best Regards
>
> Jeff Zhang
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


[GitHub] zeppelin issue #3235: [ZEPPELIN-3864] Fix Travis tests

2018-12-11 Thread Savalek
Github user Savalek commented on the issue:

https://github.com/apache/zeppelin/pull/3235
  
@felixcheung, I'm trying to fix the tests but I can't even run `npm run 
test` in `zeppelin-web` because the file `webpack.config.js` made for version 
`webpack 1` but the current version `4`. 
They are not compatible between. 
In addition, I counted at least 33 broken tests.
And i'm not strong in the frontend.


---