Stop Thinking, Just Do!

Sung-Soo Kim's Blog

Zeppelin Structure


24 November 2015

Zeppelin Structure

How to contribute

Zeppelin is Apache2 License Software. Contributing to Zeppelin (Source code, Documents, Image, Website) means you agree to the Apache2 License.

  1. Make sure your issue is not already in the Jira issue tracker
  2. If not, create a ticket describing the change you’re proposing in the Jira issue tracker
  3. Contribute your patch via Pull Request.

SourceControl Workflow

Zeppelin follows [Fork & Pull] (,-Branching,-Commits,-and-Pull-Request) model.

Setting up

Here are some things you will need to build and test Zeppelin.

Software Configuration Management(SCM)

Zeppelin uses Git for it’s SCM system. Hosted by You’ll need git client installed in your development machine.

Integrated Development Environment(IDE)

You are free to use whatever IDE you prefer, or your favorite command line editor.

Project Structure

Zeppelin project is based on Maven. Maven works by convention & defines [directory structure] ( for a project. The top level pom.xml describes the basic project structure. Currently Zeppelin has the following modules.


Code convention

We are following Google Code style:

Checkstyle report location are in ${submodule}/target/site/checkstyle.html Test coverage report location are in ${submodule}/target/site/cobertura/index.html

Build Tools

To build the code, install

  • Oracle Java 7
  • Apache Maven

Getting the source code

First of all, you need the Zeppelin source code. The official location for Zeppelin is

git access

Get the source code on your development machine using git.

git clone zeppelin

You may also want to develop against a specific release. For example, for branch-0.1

git clone -b branch-0.1 zeppelin

Fork repository

If you want not only build Zeppelin but also make change, then you need fork Zeppelin repository and make pull request.


mvn install

To skip test

mvn install -DskipTests

To build with specific spark / hadoop version

mvn install -Phadoop-2.2 -Dhadoop.version=2.2.0 -Pspark-1.3 -Dspark.version=1.3.0


Each new File should have its own accompanying unit tests. Each new interpreter should have come with its tests.

Zeppelin has 3 types of tests:

  1. Unit Tests: The unit tests run as part of each package’s build. E.g SparkInterpeter Module’s unit test is SparkInterpreterTest
  2. Integration Tests: The intergration tests run after all modules are build. The integration tests launch an instance of Zeppelin server. ZeppelinRestApiTest is an example integration test.
  3. GUI integration tests: These tests validate the Zeppelin UI elements. These tests require a running Zepplein server and lauches a web browser to validate Notebook UI elements like Notes and their execution. See ZeppelinIT as an example.

Currently the GUI integration tests are not run in the Maven and are only run in the CI environment when the pull request is submitted to github. Make sure to watch the [CI results] ( for your pull request.

Continuous Integration

Zeppelin uses Travis for CI. In the project root there is .travis.yml that configures CI and [publishes CI results] (

Run Zepplin server in development mode

cd zeppelin-server
HADOOP_HOME=YOUR_HADOOP_HOME JAVA_HOME=YOUR_JAVA_HOME mvn exec:java -Dexec.mainClass="com.nflabs.zeppelin.server.ZeppelinServer" -Dexec.args=""

or use daemon script

bin/zeppelin-daemon start

Server will be run on http://localhost:8080


Zeppelin manages it’s issues in Jira.

Stay involved

Everyone is welcome to join our mailling list:

comments powered by Disqus