Github user ejono commented on the issue:
https://github.com/apache/zeppelin/pull/1787
When I compile Zeppelin (from master, including this change) against Spark
2.1.0, I hit the following error:
[ERROR]
/Volumes/Amazon/oss-workspace/src/zeppelin/spark/src/main/java/org/apache/zeppelin/spark/SparkInterpreter.java:[1454,26]
constructor SecurityManager in class org.apache.spark.SecurityManager cannot
be applied to given types;
required: org.apache.spark.SparkConf,scala.Option<byte[]>
found: org.apache.spark.SparkConf
reason: actual and formal argument lists differ in length
[ERROR]
/Volumes/Amazon/oss-workspace/src/zeppelin/spark/src/main/java/org/apache/zeppelin/spark/SparkInterpreter.java:[1465,22]
constructor SecurityManager in class org.apache.spark.SecurityManager cannot
be applied to given types;
required: org.apache.spark.SparkConf,scala.Option<byte[]>
found: org.apache.spark.SparkConf
reason: actual and formal argument lists differ in length
It doesn't matter if I'm using Scala 2.10 or 2.11. I can reproduce this
with a command as simple as:
mvn clean package -DskipTests -Pspark-2.0 -Dspark.version=2.1.0
I'm not all that familiar with Scala, but I don't understand why this is a
problem, as this Optional<byte[]> argument of the SecurityManager class (from
Spark's source code) has a default of None, so I wouldn't think that it would
be necessary to specify this second parameter to the constructor in Zeppelin
code. Is it not possible for Java code to take advantage of the default value
specified in the Scala code?
Also, isn't this breaking the Zeppelin CI? I don't know where to find the
Zeppelin CI, so could somebody please provide a link?
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
