From 5fa97b7a90efb7a0ab35f0dbe4926e8e4ddf58d8 Mon Sep 17 00:00:00 2001 From: Prabhjyot Singh Date: Fri, 10 Jun 2016 22:49:32 +0530 Subject: [PATCH] missing "incubation-" references --- docs/install/virtual_machine.md | 6 +++--- docs/security/notebook_authorization.md | 4 ++-- scripts/vagrant/zeppelin-dev/.gitignore | 2 +- scripts/vagrant/zeppelin-dev/README.md | 6 +++--- scripts/vagrant/zeppelin-dev/show-instructions.sh | 6 +++--- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/install/virtual_machine.md b/docs/install/virtual_machine.md index 7e454faa7a6..12f1ce4375b 100644 --- a/docs/install/virtual_machine.md +++ b/docs/install/virtual_machine.md @@ -62,7 +62,7 @@ curl -fsSL https://raw.githubusercontent.com/NFLabs/z-manager/master/zeppelin-in ### Building Zeppelin -You can now `git clone git://git.apache.org/incubator-zeppelin.git` into a directory on your host machine, or directly in your virtual machine. +You can now `git clone git://git.apache.org/zeppelin.git` into a directory on your host machine, or directly in your virtual machine. Cloning Zeppelin into the `/scripts/vagrant/zeppelin-dev` directory from the host, will allow the directory to be shared between your host and the guest machine. @@ -71,7 +71,7 @@ Cloning the project again may seem counter intuitive, since this script likley o Synced folders enable Vagrant to sync a folder on the host machine to the guest machine, allowing you to continue working on your project's files on your host machine, but use the resources in the guest machine to compile or run your project. _[(1) Synced Folder Description from Vagrant Up](https://docs.vagrantup.com/v2/synced-folders/index.html)_ By default, Vagrant will share your project directory (the directory with the Vagrantfile) to `/vagrant`. Which means you should be able to build within the guest machine after you -`cd /vagrant/incubator-zeppelin` +`cd /vagrant/zeppelin` ### What's in this VM? @@ -101,7 +101,7 @@ The virtual machine consists of: This assumes you've already cloned the project either on the host machine in the zeppelin-dev directory (to be shared with the guest machine) or cloned directly into a directory while running inside the guest machine. The following build steps will also include Python and R support via PySpark and SparkR: ``` -cd /incubator-zeppelin +cd /zeppelin mvn clean package -Pspark-1.6 -Ppyspark -Phadoop-2.4 -Psparkr -DskipTests ./bin/zeppelin-daemon.sh start ``` diff --git a/docs/security/notebook_authorization.md b/docs/security/notebook_authorization.md index 34888ea6b4a..7793d4f2235 100644 --- a/docs/security/notebook_authorization.md +++ b/docs/security/notebook_authorization.md @@ -45,11 +45,11 @@ If someone who doesn't have **read** permission is trying to access the notebook In this section, we will explain the detail about how the notebook authorization works in backend side. #### NotebookServer -The [NotebookServer](https://github.com/apache/incubator-zeppelin/blob/master/zeppelin-server/src/main/java/org/apache/zeppelin/socket/NotebookServer.java) classifies every notebook operations into three categories: **Read**, **Write**, **Manage**. +The [NotebookServer](https://github.com/apache/zeppelin/blob/master/zeppelin-server/src/main/java/org/apache/zeppelin/socket/NotebookServer.java) classifies every notebook operations into three categories: **Read**, **Write**, **Manage**. Before executing a notebook operation, it checks if the user and the groups associated with the `NotebookSocket` have permissions. For example, before executing a **Read** operation, it checks if the user and the groups have at least one entity that belongs to the **Reader** entities. #### Notebook REST API call -Zeppelin executes a [REST API call](https://github.com/apache/incubator-zeppelin/blob/master/zeppelin-server/src/main/java/org/apache/zeppelin/rest/NotebookRestApi.java) for the notebook permission information. +Zeppelin executes a [REST API call](https://github.com/apache/zeppelin/blob/master/zeppelin-server/src/main/java/org/apache/zeppelin/rest/NotebookRestApi.java) for the notebook permission information. In the backend side, Zeppelin gets the user information for the connection and allows the operation if the users and groups associated with the current user have at least one entity that belongs to owner entities for the notebook. diff --git a/scripts/vagrant/zeppelin-dev/.gitignore b/scripts/vagrant/zeppelin-dev/.gitignore index c5ab41ff97a..e4b9813f24e 100644 --- a/scripts/vagrant/zeppelin-dev/.gitignore +++ b/scripts/vagrant/zeppelin-dev/.gitignore @@ -1,4 +1,4 @@ .vagrant .DS_Store -incubator-zeppelin +zeppelin diff --git a/scripts/vagrant/zeppelin-dev/README.md b/scripts/vagrant/zeppelin-dev/README.md index 60e9708369b..9e5c9c9cebe 100644 --- a/scripts/vagrant/zeppelin-dev/README.md +++ b/scripts/vagrant/zeppelin-dev/README.md @@ -47,7 +47,7 @@ curl -fsSL https://raw.githubusercontent.com/NFLabs/z-manager/master/zeppelin-in ### Building Zeppelin -You can now `git clone git://git.apache.org/incubator-zeppelin.git` into a directory on your host machine, or directly in your virtual machine. +You can now `git clone git://git.apache.org/zeppelin.git` into a directory on your host machine, or directly in your virtual machine. Cloning zeppelin into the `/scripts/vagrant/zeppelin-dev` directory from the host, will allow the directory to be shared between your host and the guest machine. @@ -56,7 +56,7 @@ Cloning the project again may seem counter intuitive, since this script likley o Synced folders enable Vagrant to sync a folder on the host machine to the guest machine, allowing you to continue working on your project's files on your host machine, but use the resources in the guest machine to compile or run your project. _[(1) Synced Folder Description from Vagrant Up](https://docs.vagrantup.com/v2/synced-folders/index.html)_ By default, Vagrant will share your project directory (the directory with the Vagrantfile) to `/vagrant`. Which means you should be able to build within the guest machine after you -`cd /vagrant/incubator-zeppelin` +`cd /vagrant/zeppelin` ### What's in this VM? @@ -86,7 +86,7 @@ The virtual machine consists of: This assumes you've already cloned the project either on the host machine in the zeppelin-dev directory (to be shared with the guest machine) or cloned directly into a directory while running inside the guest machine. The following build steps will also include Python and R support via PySpark and SparkR: ``` -cd /incubator-zeppelin +cd /zeppelin mvn clean package -Pspark-1.6 -Ppyspark -Phadoop-2.4 -Psparkr -DskipTests ./bin/zeppelin-daemon.sh start ``` diff --git a/scripts/vagrant/zeppelin-dev/show-instructions.sh b/scripts/vagrant/zeppelin-dev/show-instructions.sh index 16a399d31f7..f3b2b27aeb9 100644 --- a/scripts/vagrant/zeppelin-dev/show-instructions.sh +++ b/scripts/vagrant/zeppelin-dev/show-instructions.sh @@ -16,9 +16,9 @@ echo '# Post vagrant up instructions.' echo '# From your host machine,' -echo '# git clone the incubator-zeppelin branch into this directory' +echo '# git clone the zeppelin branch into this directory' echo -echo 'git clone git://git.apache.org/incubator-zeppelin.git' +echo 'git clone git://git.apache.org/zeppelin.git' echo echo '# Cloning the project again may seem counter intuitive, since this script' echo '# originated from the project repository. Consider copying just the vagrant/zeppelin-dev' @@ -29,7 +29,7 @@ echo 'vagrant ssh' echo echo '# then when running inside the VM' echo -echo 'cd /vagrant/incubator-zeppelin' +echo 'cd /vagrant/zeppelin' echo 'mvn clean package -DskipTests' echo echo '# or for a specific Spark/Hadoop build with additional options such as python and R support'