You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ho...@apache.org on 2017/05/10 21:43:09 UTC

[48/50] [abbrv] lucene-solr:master: squash merge jira/solr-10290 into master

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/feedback.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/feedback.html b/solr/solr-ref-guide/src/_includes/feedback.html
new file mode 100755
index 0000000..bcd5fbc
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/feedback.html
@@ -0,0 +1,16 @@
+<!-- Send feedback function -->
+<script>
+function SendLinkByMail(href) {
+var subject= "{{site.site_title}} feedback";
+var body = "I have some feedback about the {{page.title}} page: ";
+body += window.location.href;
+body += "";
+var uri = "mailto:{{site.feedback_email}}?subject=";
+uri += encodeURIComponent(subject);
+uri += "&body=";
+uri += encodeURIComponent(body);
+window.location.href = uri;
+}
+</script>
+
+<li><a href="{% if site.feedback_link %}{{site.feedback_link}}{% else %}javascript:(function()%7BSendLinkByMail()%3B%7D)()%3B{% endif %}" target="_blank">{% if site.feedback_link == null %}<i class="fa fa-envelope-o"></i>{% endif %} {% if site.feedback_text %}{{site.feedback_text}}{% else %}Feedback{% endif %}</a></li>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/footer.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/footer.html b/solr/solr-ref-guide/src/_includes/footer.html
new file mode 100755
index 0000000..c22f239
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/footer.html
@@ -0,0 +1,9 @@
+<footer>
+            <div class="row">
+                <div class="col-lg-12 footer">
+               &copy;{{ site.solr-attributes.build-year }} {{site.company_name}}. All rights reserved. <br />
+{% if page.last_updated %}<p>Page last updated:</span> {{page.last_updated}}<br/>{% endif %} Site last generated: {{ site.solr-attributes.build-date }} <br />
+<p><img src="{{ "solr-sunOnly-small.png" }}" alt="Apache Solr"/></p>
+                </div>
+            </div>
+</footer>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/google_analytics.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/google_analytics.html b/solr/solr-ref-guide/src/_includes/google_analytics.html
new file mode 100755
index 0000000..56b2ee8
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/google_analytics.html
@@ -0,0 +1,6 @@
+<!-- the google_analytics_id gets auto inserted from the config file -->
+
+{% if site.google_analytics %}
+
+<script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','//www.google-analytics.com/analytics.js','ga');ga('create','{{site.google_analytics}}','auto');ga('require','displayfeatures');ga('send','pageview');</script>
+{% endif %}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/head.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/head.html b/solr/solr-ref-guide/src/_includes/head.html
new file mode 100755
index 0000000..03b0db8
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/head.html
@@ -0,0 +1,34 @@
+<meta charset="utf-8">
+<meta http-equiv="X-UA-Compatible" content="IE=edge">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<meta name="description" content="{% if page.description %}{{ page.description | strip_html | strip_newlines | truncate: 160 }}{% endif %}">
+<meta name="keywords" content="{{page.tags}}{% if page.tags %}, {% endif %} {{page.keywords}}">
+<title>{{ page.title }} | {{ site.site_title }}</title>
+
+<link rel="stylesheet" type="text/css" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+<!--<link rel="stylesheet" type="text/css" href="css/bootstrap.min.css">-->
+<link rel="stylesheet" href="{{ "css/lavish-bootstrap.css" }}">
+<link rel="stylesheet" href="{{ "css/customstyles.css" }}">
+<link rel="stylesheet" href="{{ "css/theme-solr.css" }}">
+<link rel="stylesheet" href="{{ "css/ref-guide.css" }}">
+<link rel="stylesheet" href="{{ "css/comments.css" }}">
+
+<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
+<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.4.1/jquery.cookie.min.js"></script>
+<script src="{{ "js/jquery.navgoco.min.js" }}"></script>
+
+<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script>
+<script src="https://cdnjs.cloudflare.com/ajax/libs/anchor-js/2.0.0/anchor.min.js"></script>
+<script src="{{ "js/toc.js" }}"></script>
+<script src="{{ "js/customscripts.js" }}"></script>
+
+<link rel="shortcut icon" href="{{ "images/favicon.ico"  }}">
+
+<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
+<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
+<!--[if lt IE 9]>
+<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+<script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
+<![endif]-->
+
+<link rel="alternate" type="application/rss+xml" title="{{ site.site_title }}" href="{{ "/feed.xml" | prepend: site.url }}">

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/head_print.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/head_print.html b/solr/solr-ref-guide/src/_includes/head_print.html
new file mode 100755
index 0000000..8f10c28
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/head_print.html
@@ -0,0 +1,33 @@
+<meta charset="utf-8">
+<meta http-equiv="X-UA-Compatible" content="IE=edge">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<meta name="description" content="{% if page.summary %}{{ page.summary | strip_html | strip_newlines | truncate: 160 }}{% endif %}">
+<meta name="keywords" content="{{page.tags}}{% if page.tags %}, {% endif %} {{page.keywords}}">
+<title>{% if page.homepage == true %} {{site.homepage_title}} {% elsif page.title %}{{ page.title }}{% endif %}  | {{ site.site_title }}</title>
+
+
+<link rel="stylesheet" href="{{ "/css/syntax.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/font-awesome.min.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/bootstrap.min.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/modern-business.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/lavish-bootstrap.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/customstyles.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/theme-green.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/syntax.css" | prepend: site.baseurl | prepend: site.url }}">
+<link rel="stylesheet" href="{{ "/css/printstyles.css" | prepend: site.baseurl }}">
+
+<script>
+    Prince.addScriptFunc("datestamp", function() {
+        return "PDF last generated: {{ site.time | date: '%B %d, %Y' }}";
+    });
+</script>
+
+<script>
+    Prince.addScriptFunc("guideName", function() {
+        return "{{site.print_title}} User Guide";
+    });
+</script>
+
+
+
+

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/image.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/image.html b/solr/solr-ref-guide/src/_includes/image.html
new file mode 100755
index 0000000..ad12972
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/image.html
@@ -0,0 +1 @@
+<figure>{% if {{include.url}} %}<a class="no_icon" target="_blank" href="{{include.url}}">{% endif %}<img class="docimage" src="images/{{include.file}}" alt="{{include.alt}}" {% if {{include.max-width}} %}style="max-width: {{include.max-width}}px"{% endif %} />{% if {{include.url}} %}</a>{% endif %}{% if {{include.caption}} %}<figcaption>{{include.caption}}</figcaption></figure>{% endif %}

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/inline_image.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/inline_image.html b/solr/solr-ref-guide/src/_includes/inline_image.html
new file mode 100755
index 0000000..1e7fd18
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/inline_image.html
@@ -0,0 +1 @@
+<img class="inline" src="images/{{include.file}}" alt="{{include.alt}}" />

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/links.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/links.html b/solr/solr-ref-guide/src/_includes/links.html
new file mode 100755
index 0000000..4f99e94
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/links.html
@@ -0,0 +1,44 @@
+{% comment %}Get links from each sidebar, as listed in the _config.yml file under sidebars{% endcomment %}
+
+{% for sidebar in site.sidebars %}
+{% for entry in site.data.sidebars[sidebar].entries %}
+{% for folder in entry.folders %}
+{% for folderitem in folder.folderitems %}
+{% if folderitem.url contains "html#" %}
+[{{folderitem.url | remove: "/" }}]: {{folderitem.url | remove: "/"}}
+{% else %}
+[{{folderitem.url | remove: "/"  | remove: ".html"}}]: {{folderitem.url | remove: "/"}}
+{% endif %}
+{% for subfolders in folderitem.subfolders %}
+{% for subfolderitem in subfolders.subfolderitems %}
+[{{subfolderitem.url | remove: "/"  | remove: ".html"}}]: {{subfolderitem.url | remove: "/"}}
+{% endfor %}
+{% endfor %}
+{% endfor %}
+{% endfor %}
+{% endfor %}
+{% endfor %}
+
+
+{% comment %} Get links from topnav {% endcomment %}
+
+{% for entry in site.data.topnav.topnav %}
+{% for item in entry.items %}
+{% if item.external_url == null %}
+[{{item.url | remove: "/" | remove: ".html"}}]: {{item.url | remove: "/"}}
+{% endif %}
+{% endfor %}
+{% endfor %}
+
+{% comment %}Get links from topnav dropdowns {% endcomment %}
+
+{% for entry in site.data.topnav.topnav_dropdowns %}
+{% for folder in entry.folders %}
+{% for folderitem in folder.folderitems %}
+{% if folderitem.external_url == null %}
+[{{folderitem.url | remove: "/"  | remove: ".html"}}]: {{folderitem.url | remove: "/"}}
+{% endif %}
+{% endfor %}
+{% endfor %}
+{% endfor %}
+

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/sidebar.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/sidebar.html b/solr/solr-ref-guide/src/_includes/sidebar.html
new file mode 100755
index 0000000..4b4124c
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/sidebar.html
@@ -0,0 +1,59 @@
+{% assign sidebar = site.data.sidebar %}
+
+<ul id="mysidebar" class="nav">
+  <li class="sidebarTitle">{{sidebar.title}} <!-- TODO: version from site.data --></li>
+  {% for level1item in sidebar.kids %}
+  <li class="sb-level1">
+    <a href="{{level1item.url | remove: "/"}}">{{ level1item.title }}</a>
+    {% if level1item.kids.size > 0 %}
+    <ul>
+      {% for level2item in level1item.kids %}
+      <li class="sb-level2">
+        <a href="{{ level2item.url | remove: "/" }}">{{ level2item.title }}</a>
+        {% if level2item.kids.size > 0 %}
+        <ul>
+          {% for level3item in level2item.kids %}
+          <li class="sb-level3">
+            <a href="{{ level3item.url | remove: "/" }}">{{ level3item.title }}</a>
+            {% if level3item.kids.size > 0 %}
+            <ul>
+              {% for level4item in level3item.kids %}
+              <li class="sb-level4">
+                <a href="{{ level4item.url | remove: "/" }}">{{ level4item.title }}</a>
+                {% comment %}
+                <!-- NOTE: adding addiional levels here will also require additional changes to 
+                     ref-guide.css in order to indent them properly
+                  -->
+                {% endcomment %}
+              </li>
+              {% endfor %}
+            </ul>
+            {% endif %}
+          </li>
+          {% endfor %}
+        </ul>
+        {% endif %}
+      </li>
+      {% endfor %}
+    </ul>
+    {% endif %}
+  </li>
+  {% endfor %}
+</ul>
+{% comment %}
+<!-- if you aren't using the accordion, uncomment this block:
+     <p class="external">
+       <a href="#" id="collapseAll">Collapse All</a> | <a href="#" id="expandAll">Expand All</a>
+     </p>
+     -->
+{% endcomment %}
+
+<!-- set the 'active' class on the current page and ancestors -->
+<!-- this highlights the active parent class in the navgoco sidebar. this is critical so that the parent expands when you're viewing a page. This must appear below the sidebar code above. Otherwise, if placed inside customscripts.js, the script runs before the sidebar code runs and the class never gets inserted.-->
+<script>$("#mysidebar a[href='{{ page.shortname }}.html']").parents('li').toggleClass("active", true);</script>
+<!-- set the 'current' class on the current page and 'current-tree' on the current page + it's ancestors -->
+<!-- this can let us do css highlighting of the current page in the sidebar even if/when the user clicks around in the sidebar causing other sidebar elements to be 'active' -->
+<script>
+  $("#mysidebar a[href='{{ page.shortname }}.html']").parent('li').toggleClass("current", true);
+  $("#mysidebar a[href='{{ page.shortname }}.html']").parents('li').toggleClass("current-tree", true);
+</script>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/taglogic.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/taglogic.html b/solr/solr-ref-guide/src/_includes/taglogic.html
new file mode 100755
index 0000000..35efc5a
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/taglogic.html
@@ -0,0 +1,22 @@
+<p>The following pages and posts are tagged with <button type="button" style="cursor: default" class="btn btn-default navbar-btn">{{page.tagName}}</button></p>
+<table><thead><tr><th>Title</th><th>Type</th><th>Excerpt</th></tr></thead>
+    <tbody>
+    {% assign thisTag = page.tagName %}
+  {% for page in site.pages %}
+    {% for tag in page.tags %}
+        {% if tag == thisTag %}
+
+        <tr><td><a href="{{ page.url | remove: "/" }}">{{page.title}}</a></td>
+            <td><span class="label label-default">Page</span></td>
+          <td>{% if page.description %}
+                {{ page.description | strip_html | strip_newlines | truncate: 160 }}
+             {% else %}
+               {{ page.content | truncatewords: 50 | strip_html }}
+             {% endif %}</td>
+        </tr>
+        {% endif %}
+     {% endfor %}
+   {% endfor %}
+
+   </tbody>
+</table>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/toc.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/toc.html b/solr/solr-ref-guide/src/_includes/toc.html
new file mode 100755
index 0000000..14f74e0
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/toc.html
@@ -0,0 +1,21 @@
+
+<!-- this handles the automatic toc. use ## for subheads to auto-generate the on-page minitoc. if you use html tags, you must supply an ID for the heading element in order for it to appear in the minitoc. -->
+<script>
+$( document ).ready(function() {
+  // Handler for .ready() called.
+
+$('#toc').toc({ minimumHeaders: 2, listType: 'ul', showSpeed: 0, headers: 'h2,h3' });
+
+/* this offset helps account for the space taken up by the floating toolbar. */
+$('#toc').on('click', 'a', function() {
+  var target = $(this.getAttribute('href'))
+    , scroll_target = target.offset().top
+
+  $(window).scrollTop(scroll_target - 10);
+  return false
+})
+
+});
+</script>
+
+<div id="toc"></div>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_includes/topnav.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_includes/topnav.html b/solr/solr-ref-guide/src/_includes/topnav.html
new file mode 100755
index 0000000..677f850
--- /dev/null
+++ b/solr/solr-ref-guide/src/_includes/topnav.html
@@ -0,0 +1,63 @@
+<!-- Navigation -->
+<nav class="navbar navbar-inverse navbar-fixed-top">
+    <div class="container topnavlinks">
+        <div class="navbar-header">
+            <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1">
+                <span class="sr-only">Toggle navigation</span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+            </button>
+            <a class="fa fa-home fa-lg navbar-brand" href="index.html">&nbsp;<span class="projectTitle"> {{site.topnav_title}} {{ site.solr-attributes.solr-docs-version }}</span></a>
+        </div>
+        <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
+            <ul class="nav navbar-nav navbar-right">
+                <!-- Link to Solr website -->
+                <li><a href="https://lucene.apache.org/solr/news" target="_blank">Solr News</a></li>
+                <!-- Other Guide Formats dropdown -->
+                <li class="dropdown">
+                    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Other Formats<b class="caret"></b></a>
+                    <ul class="dropdown-menu">
+                       <li><a href="https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide" target="_blank">PDF for Latest Release</a></li>
+                       <li><a href="https://archive.apache.org/dist/lucene/solr/ref-guide/" target="_blank">Archived PDFs</a></li>
+                       <li><a href="https://lucene.apache.org/solr/guide/" target="_blank">Other Versions Online</a></li>
+                    </ul>
+                </li>
+                <!-- Solr Resources dropdown -->
+                <li class="dropdown">
+                    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Solr Resources<b class="caret"></b></a>
+                    <ul class="dropdown-menu">
+                       <li><a href="{{site.solr-attributes.solr-javadocs}}/solr-core/index.html" target="_blank">Solr Javadocs</a></li>
+                       <li><a href="https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git" target="_blank">Lucene/Solr Source Code</a></li>
+                       <li><a href="https://lucene.apache.org/solr/resources.html#community" target="_blank">Solr Community Links</a></li>
+                    </ul>
+                </li>
+                {% if site.feedback_disable == null or site.feedback_disable == false %}
+                   {% include feedback.html %}
+                {% endif %}
+                <!--comment out this block if you want to hide search-->
+                <li>
+                    <!--start search-->
+                    <div id="search-demo-container">
+                        <input type="text" id="search-input" placeholder="{{site.data.strings.search_placeholder_text}}">
+                        <ul id="results-container"></ul>
+                    </div>
+                    <script src="{{ "js/jekyll-search.js"}}" type="text/javascript"></script>
+                    <script type="text/javascript">
+                            SimpleJekyllSearch.init({
+                                searchInput: document.getElementById('search-input'),
+                                resultsContainer: document.getElementById('results-container'),
+                                dataSource: '{{ "search.json" }}',
+                                searchResultTemplate: '<li><a href="{url}" title="{{page.title | replace: "'", "\"}}">{title}</a></li>',
+                    noResultsText: '{{site.data.strings.search_no_results_text}}',
+                            limit: 10,
+                            fuzzy: true,
+                    })
+                    </script>
+                    <!--end search-->
+                </li>
+            </ul>
+        </div>
+        </div>
+        <!-- /.container -->
+</nav>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/default.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/default.html b/solr/solr-ref-guide/src/_layouts/default.html
new file mode 100755
index 0000000..aa4601f
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/default.html
@@ -0,0 +1,55 @@
+<!DOCTYPE html>
+<head>
+    {% include head.html %}
+    <script>
+        $(document).ready(function() {
+            // Initialize navgoco with default options
+            $("#mysidebar").navgoco({
+                caretHtml: '',
+                accordion: true,
+                openClass: 'active', // open
+                save: false, // we do *NOT* want cookies used to save the current stage of the sidebar
+                             // instead the code in sidebar.html will ensure that the current page
+                             // (and it's ancestors) are "active" on page load
+                slide: {
+                    duration: 400,
+                    easing: 'swing'
+                }
+            });
+
+            $("#collapseAll").click(function(e) {
+                e.preventDefault();
+                $("#mysidebar").navgoco('toggle', false);
+            });
+
+            $("#expandAll").click(function(e) {
+                e.preventDefault();
+                $("#mysidebar").navgoco('toggle', true);
+            });
+
+        });
+
+    </script>
+</head>
+<body id="{{ page.shortname }}">
+{% include topnav.html %}
+<!-- Page Content -->
+<div class="container">
+  <div class="col-lg-12">&nbsp;</div>
+  <!-- Content Row -->
+  <div class="row">
+    <!-- Sidebar Column -->
+    <div class="col-md-3">
+      {% include sidebar.html %}
+    </div>
+    <!-- Content Column -->
+    <div class="col-md-9">
+      {{content}}
+    </div>
+    <!-- /.row -->
+  </div>
+  <!-- /.container -->
+</div>
+
+</body>
+</html>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/default_print.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/default_print.html b/solr/solr-ref-guide/src/_layouts/default_print.html
new file mode 100755
index 0000000..4bf619b
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/default_print.html
@@ -0,0 +1,25 @@
+<!DOCTYPE html>
+<html lang="en">
+<html>
+<head>
+    {% include head_print.html %}
+
+
+</head>
+
+<body class="{% if page.type == "title"%}title{% elsif page.type == "frontmatter" %}frontmatter{% elsif page.type == "first_page" %}first_page{% endif %} print">
+
+<!-- Page Content -->
+<div class="container">
+    <!-- Content Column -->
+    <div class="col-md-9">
+
+        {{content}}
+    </div>
+
+</div>    <!-- /.container -->
+
+</body>
+
+</html>
+

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/none.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/none.html b/solr/solr-ref-guide/src/_layouts/none.html
new file mode 100755
index 0000000..60887a9
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/none.html
@@ -0,0 +1,3 @@
+---
+---
+{{content}}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/page.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/page.html b/solr/solr-ref-guide/src/_layouts/page.html
new file mode 100755
index 0000000..20758da
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/page.html
@@ -0,0 +1,80 @@
+---
+layout: default
+---
+
+<div class="post-header">
+   <h1 class="post-title-main">{{ page.title }}</h1>
+</div>
+
+<!-- This adds a workflow map, to a page
+     See http://idratherbewriting.com/documentation-theme-jekyll/mydoc_workflow_maps.html
+     Leaving it here commented out in case we want to implement this in the future
+{% if page.simple_map == true %}
+<script>
+    $(document).ready ( function(){
+        $('.box{{page.box_number}}').addClass('active');
+    });
+</script>
+{% include custom/{{page.map_name}}.html %}
+{% elsif page.complex_map == true %}
+<script>
+    $(document).ready ( function(){
+        $('.modalButton{{page.box_number}}').addClass('active');
+    });
+</script>
+{% include custom/{{page.map_name}}.html %}
+{% endif %} -->
+
+<div class="post-content">
+
+   {% if page.summary %}
+    <div class="summary">{{ page.summary }}</div>
+   {% endif %}
+
+    {% unless page.toc == false %}
+    {% include toc.html %}
+    {% endunless %}
+
+<div class="main-content">
+  {{content}}
+</div>
+
+<!-- Adds tags, if any -->
+    <div class="tags">
+        {% if page.tags != null %}
+        <b>Tags: </b>
+        {% assign projectTags = site.data.tags.allowed-tags %}
+        {% for tag in page.tags %}
+        {% if projectTags contains tag %}
+        <a href="{{ "tag-" | append: tag | append: ".html" }}" class="btn btn-default navbar-btn cursorNorm" role="button">{{page.tagName}}{{tag}}</a>
+        {% endif %}
+        {% endfor %}
+        {% endif %}
+    </div>
+
+<!-- Adds nav links on each page -->
+    {% assign scrollnav = site.data.scrollnav[page.shortname] %}
+    {% if scrollnav %}
+    <div class="scrollnav">
+      {% if scrollnav.prev %}
+      <a class="btn btn-primary prev" href="{{ scrollnav.prev.url }}">{{ scrollnav.prev.title }}</a>
+      {% endif %}
+      {% if scrollnav.next %}
+      <a class="btn btn-primary next" href="{{ scrollnav.next.url }}">{{ scrollnav.next.title }}</a>
+      {% endif %}
+    </div>
+    {% endif %}
+
+</div>
+
+<!-- Adds comments from Apache's Comment system -->
+
+<div id="comments_thread">
+</div>
+<script type="text/javascript" src="https://comments.apache.org/show_comments.lua?site=solr-refguide&style=css/comments.css&page={{ page.shortname }}" async="true">
+</script>
+<noscript>
+<iframe width="100%" height="500" src="https://comments.apache.org/iframe.lua?site=solr-refguide&style=css/comments.css&page={{ page.shortname }}"></iframe>
+</noscript>
+
+{% include footer.html %}

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/page_print.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/page_print.html b/solr/solr-ref-guide/src/_layouts/page_print.html
new file mode 100755
index 0000000..9e04604
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/page_print.html
@@ -0,0 +1,15 @@
+---
+layout: default_print
+comments: true
+---
+<div class="post-header">
+    <h1 class="post-title-main" id="{{page.permalink | replace: '/', '' }}">{{ page.title }}</h1>
+</div>
+
+<div class="post-content">
+
+    {% if page.summary %}
+    <div class="summary">{{page.summary}}</div>
+    {% endif %}
+    {{ content }}
+</div>

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/_layouts/post.html
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/_layouts/post.html b/solr/solr-ref-guide/src/_layouts/post.html
new file mode 100755
index 0000000..d1ba8f1
--- /dev/null
+++ b/solr/solr-ref-guide/src/_layouts/post.html
@@ -0,0 +1,41 @@
+---
+layout: default
+---
+<article class="post" itemscope itemtype="http://schema.org/BlogPosting">
+
+    <header class="post-header">
+        <h1 class="post-title" itemprop="name headline">{{ page.title }}</h1>
+        <p class="post-meta"><time datetime="{{ page.date | date_to_xmlschema }}" itemprop="datePublished">{{ page.date | date: "%b %-d, %Y" }}</time> {% if page.author %}<span itemprop="author" itemscope itemtype="http://schema.org/Person"><span itemprop="name">/ {{ page.author }}</span></span>{% endif %}{% if page.tags != null %}/
+            {% assign projectTags = site.data.tags.allowed-tags %}
+            {% for tag in page.tags %}
+            {% if projectTags contains tag %}
+            <a href="{{ "../tag_" | append: tag | append: ".html" }}">{{tag}}</a>{% unless forloop.last %}, {% endunless%}
+            {% endif %}
+            {% endfor %}
+            {% endif %}
+
+        </p>
+
+
+    </header>
+
+    <div class="post-content" itemprop="articleBody">
+
+        {% if page.summary %}
+        <div class="summary">{{page.summary}}</div>
+        {% endif %}
+
+        {{ content }}
+    </div>
+
+
+
+</article>
+
+{% if site.disqus %}
+{% include disqus.html %}
+{% endif %}
+
+{{site.data.alerts.hr_shaded}}
+
+{% include footer.html %}

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/a-quick-overview.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/a-quick-overview.adoc b/solr/solr-ref-guide/src/a-quick-overview.adoc
new file mode 100644
index 0000000..b87d091
--- /dev/null
+++ b/solr/solr-ref-guide/src/a-quick-overview.adoc
@@ -0,0 +1,33 @@
+= A Quick Overview
+:page-shortname: a-quick-overview
+:page-permalink: a-quick-overview.html
+
+Having had some fun with Solr, you will now learn about all the cool things it can do.
+
+Here is a example of how Solr might be integrated into an application:
+
+.Solr integration with applications
+image::images/a-quick-overview/sample-client-app-arch.png[image,width=500,height=379]
+
+In the scenario above, Solr runs along side other server applications. For example, an online store application would provide a user interface, a shopping cart, and a way to make purchases for end users; while an inventory management application would allow store employees to edit product information. The product metadata would be kept in some kind of database, as well as in Solr.
+
+Solr makes it easy to add the capability to search through the online store through the following steps:
+
+. Define a _schema_. The schema tells Solr about the contents of documents it will be indexing. In the online store example, the schema would define fields for the product name, description, price, manufacturer, and so on. Solr's schema is powerful and flexible and allows you to tailor Solr's behavior to your application. See <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,Documents, Fields, and Schema Design>> for all the details.
+. Deploy Solr.
+. Feed Solr documents for which your users will search.
+. Expose search functionality in your application.
+
+Because Solr is based on open standards, it is highly extensible. Solr queries are RESTful, which means, in essence, that a query is a simple HTTP request URL and the response is a structured document: mainly XML, but it could also be JSON, CSV, or some other format. This means that a wide variety of clients will be able to use Solr, from other web applications to browser clients, rich client applications, and mobile devices. Any platform capable of HTTP can talk to Solr. See <<client-apis.adoc#client-apis,Client APIs>> for details on client APIs.
+
+Solr is based on the Apache Lucene project, a high-performance, full-featured search engine. Solr offers support for the simplest keyword searching through to complex queries on multiple fields and faceted search results. <<searching.adoc#searching,Searching>> has more information about searching and queries.
+
+If Solr's capabilities are not impressive enough, its ability to handle very high-volume applications should do the trick.
+
+A relatively common scenario is that you have so much data, or so many queries, that a single Solr server is unable to handle your entire workload. In this case, you can scale up the capabilities of your application using <<solrcloud.adoc#solrcloud,SolrCloud>> to better distribute the data, and the processing of requests, across many servers. Multiple options can be mixed and matched depending on the type of scalability you need.
+
+For example: "Sharding" is a scaling technique in which a collection is split into multiple logical pieces called "shards" in order to scale up the number of documents in a collection beyond what could physically fit on a single server. Incoming queries are distributed to every shard in the collection, which respond with merged results. Another technique available is to increase the "Replication Factor" of your collection, which allows you to add servers with additional copies of your collection to handle higher concurrent query load by spreading the requests around to multiple machines. Sharding and Replication are not mutually exclusive, and together make Solr an extremely powerful and scalable platform.
+
+Best of all, this talk about high-volume applications is not just hypothetical: some of the famous Internet sites that use Solr today are Macy's, EBay, and Zappo's.
+
+For more information, take a look at https://wiki.apache.org/solr/PublicServers.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/a-step-closer.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/a-step-closer.adoc b/solr/solr-ref-guide/src/a-step-closer.adoc
new file mode 100644
index 0000000..f74d214
--- /dev/null
+++ b/solr/solr-ref-guide/src/a-step-closer.adoc
@@ -0,0 +1,54 @@
+= A Step Closer
+:page-shortname: a-step-closer
+:page-permalink: a-step-closer.html
+
+You already have some idea of Solr's schema. This section describes Solr's home directory and other configuration options.
+
+When Solr runs in an application server, it needs access to a home directory. The home directory contains important configuration information and is the place where Solr will store its index. The layout of the home directory will look a little different when you are running Solr in standalone mode vs when you are running in SolrCloud mode.
+
+The crucial parts of the Solr home directory are shown in these examples:
+
+.Standalone Mode
+[source,plain]
+----
+<solr-home-directory>/
+   solr.xml
+   core_name1/
+      core.properties
+      conf/
+         solrconfig.xml
+         managed-schema
+      data/
+   core_name2/
+      core.properties
+      conf/
+         solrconfig.xml
+         managed-schema
+      data/
+----
+
+.SolrCloud Mode
+[source,plain]
+----
+<solr-home-directory>/
+   solr.xml
+   core_name1/
+      core.properties
+      data/
+   core_name2/
+      core.properties
+      data/
+----
+
+You may see other files, but the main ones you need to know are:
+
+* `solr.xml` specifies configuration options for your Solr server instance. For more information on `solr.xml` see <<solr-cores-and-solr-xml.adoc#solr-cores-and-solr-xml,Solr Cores and solr.xml>>.
+* Per Solr Core:
+** `core.properties` defines specific properties for each core such as its name, the collection the core belongs to, the location of the schema, and other parameters. For more details on `core.properties`, see the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>>.
+** `solrconfig.xml` controls high-level behavior. You can, for example, specify an alternate location for the data directory. For more information on `solrconfig.xml`, see <<configuring-solrconfig-xml.adoc#configuring-solrconfig-xml,Configuring solrconfig.xml>>.
+** `managed-schema` (or `schema.xml` instead) describes the documents you will ask Solr to index. The Schema define a document as a collection of fields. You get to define both the field types and the fields themselves. Field type definitions are powerful and include information about how Solr processes incoming field values and query values. For more information on Solr Schemas, see <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,Documents, Fields, and Schema Design>> and the <<schema-api.adoc#schema-api,Schema API>>.
+** `data/` The directory containing the low level index files.
+
+Note that the SolrCloud example does not include a `conf` directory for each Solr Core (so there is no `solrconfig.xml` or Schema file). This is because the configuration files usually found in the `conf` directory are stored in ZooKeeper so they can be propagated across the cluster.
+
+If you are using SolrCloud with the embedded ZooKeeper instance, you may also see `zoo.cfg` and `zoo.data` which are ZooKeeper configuration and data files. However, if you are running your own ZooKeeper ensemble, you would supply your own ZooKeeper configuration file when you start it and the copies in Solr would be unused. For more information about ZooKeeper and SolrCloud, see the section <<solrcloud.adoc#solrcloud,SolrCloud>>.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/about-filters.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/about-filters.adoc b/solr/solr-ref-guide/src/about-filters.adoc
new file mode 100644
index 0000000..84e3b95
--- /dev/null
+++ b/solr/solr-ref-guide/src/about-filters.adoc
@@ -0,0 +1,29 @@
+= About Filters
+:page-shortname: about-filters
+:page-permalink: about-filters.html
+
+Like <<tokenizers.adoc#tokenizers,tokenizers>>, <<filter-descriptions.adoc#filter-descriptions,filters>> consume input and produce a stream of tokens. Filters also derive from `org.apache.lucene.analysis.TokenStream`. Unlike tokenizers, a filter's input is another TokenStream. The job of a filter is usually easier than that of a tokenizer since in most cases a filter looks at each token in the stream sequentially and decides whether to pass it along, replace it or discard it.
+
+A filter may also do more complex analysis by looking ahead to consider multiple tokens at once, although this is less common. One hypothetical use for such a filter might be to normalize state names that would be tokenized as two words. For example, the single token "california" would be replaced with "CA", while the token pair "rhode" followed by "island" would become the single token "RI".
+
+Because filters consume one `TokenStream` and produce a new `TokenStream`, they can be chained one after another indefinitely. Each filter in the chain in turn processes the tokens produced by its predecessor. The order in which you specify the filters is therefore significant. Typically, the most general filtering is done first, and later filtering stages are more specialized.
+
+[source,xml]
+----
+<fieldType name="text" class="solr.TextField">
+  <analyzer>
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.StandardFilterFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+    <filter class="solr.EnglishPorterFilterFactory"/>
+  </analyzer>
+</fieldType>
+----
+
+This example starts with Solr's standard tokenizer, which breaks the field's text into tokens. Those tokens then pass through Solr's standard filter, which removes dots from acronyms, and performs a few other common operations. All the tokens are then set to lowercase, which will facilitate case-insensitive matching at query time.
+
+The last filter in the above example is a stemmer filter that uses the Porter stemming algorithm. A stemmer is basically a set of mapping rules that maps the various forms of a word back to the base, or _stem_, word from which they derive. For example, in English the words "hugs", "hugging" and "hugged" are all forms of the stem word "hug". The stemmer will replace all of these terms with "hug", which is what will be indexed. This means that a query for "hug" will match the term "hugged", but not "huge".
+
+Conversely, applying a stemmer to your query terms will allow queries containing non stem terms, like "hugging", to match documents with different variations of the same stem word, such as "hugged". This works because both the indexer and the query will map to the same stem ("hug").
+
+Word stemming is, obviously, very language specific. Solr includes several language-specific stemmers created by the http://snowball.tartarus.org/[Snowball] generator that are based on the Porter stemming algorithm. The generic Snowball Porter Stemmer Filter can be used to configure any of these language stemmers. Solr also includes a convenience wrapper for the English Snowball stemmer. There are also several purpose-built stemmers for non-English languages. These stemmers are described in <<language-analysis.adoc#language-analysis,Language Analysis>>.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/about-this-guide.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/about-this-guide.adoc b/solr/solr-ref-guide/src/about-this-guide.adoc
new file mode 100644
index 0000000..a9d1564
--- /dev/null
+++ b/solr/solr-ref-guide/src/about-this-guide.adoc
@@ -0,0 +1,57 @@
+= About This Guide
+:page-shortname: about-this-guide
+:page-permalink: about-this-guide.html
+
+This guide describes all of the important features and functions of Apache Solr.
+
+Solr is free to download from http://lucene.apache.org/solr/.
+
+Designed to provide high-level documentation, this guide is intended to be more encyclopedic and less of a cookbook. It is structured to address a broad spectrum of needs, ranging from new developers getting started to well-experienced developers extending their application or troubleshooting. It will be of use at any point in the application life cycle, for whenever you need authoritative information about Solr.
+
+The material as presented assumes that you are familiar with some basic search concepts and that you can read XML. It does not assume that you are a Java programmer, although knowledge of Java is helpful when working directly with Lucene or when developing custom extensions to a Lucene/Solr installation.
+
+[[AboutThisGuide-SpecialInlineNotes]]
+== Special Inline Notes
+
+Special notes are included throughout these pages. There are several types of notes:
+
+Information blocks::
++
+NOTE: These provide additional information that's useful for you to know.
+
+Important::
++
+IMPORTANT: These provide information that is critical for you to know.
+
+Tip::
++
+TIP: These provide helpful tips.
+
+Caution::
++
+CAUTION: These provide details on scenarios or configurations you should be careful with.
+
+Warning::
++
+WARNING: These are meant to warn you from a possibly dangerous change or action.
+
+
+[[AboutThisGuide-HostsandPortExamples]]
+== Hosts and Port Examples
+
+The default port when running Solr is 8983. The samples, URLs and screenshots in this guide may show different ports, because the port number that Solr uses is configurable. If you have not customized your installation of Solr, please make sure that you use port 8983 when following the examples, or configure your own installation to use the port numbers shown in the examples. For information about configuring port numbers, see the section <<managing-solr.adoc#managing-solr,Managing Solr>>.
+
+Similarly, URL examples use 'localhost' throughout; if you are accessing Solr from a location remote to the server hosting Solr, replace 'localhost' with the proper domain or IP where Solr is running.
+
+For example, we might provide a sample query like:
+
+`\http://localhost:8983/solr/gettingstarted/select?q=brown+cow`
+
+There are several items in this URL you might need to change locally. First, if your server is running at "www.example.com", you'll replace "localhost" with the proper domain. If you aren't using port 8983, you'll replace that also. Finally, you'll want to replace "gettingstarted" (the collection or core name) with the proper one in use in your implementation. The URL would then become:
+
+`\http://www.example.com/solr/mycollection/select?q=brown+cow`
+
+[[AboutThisGuide-Paths]]
+== Paths
+
+Path information is given relative to `solr.home`, which is the location under the main Solr installation where Solr's collections and their `conf` and `data` directories are stored. When running the various examples mentioned through out this tutorial (i.e., `bin/solr -e techproducts`) the `solr.home` will be a sub-directory of `example/` created for you automatically.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/about-tokenizers.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/about-tokenizers.adoc b/solr/solr-ref-guide/src/about-tokenizers.adoc
new file mode 100644
index 0000000..4dec7cf
--- /dev/null
+++ b/solr/solr-ref-guide/src/about-tokenizers.adoc
@@ -0,0 +1,31 @@
+= About Tokenizers
+:page-shortname: about-tokenizers
+:page-permalink: about-tokenizers.html
+
+The job of a <<tokenizers.adoc#tokenizers,tokenizer>> is to break up a stream of text into tokens, where each token is (usually) a sub-sequence of the characters in the text. An analyzer is aware of the field it is configured for, but a tokenizer is not. Tokenizers read from a character stream (a Reader) and produce a sequence of Token objects (a TokenStream).
+
+Characters in the input stream may be discarded, such as whitespace or other delimiters. They may also be added to or replaced, such as mapping aliases or abbreviations to normalized forms. A token contains various metadata in addition to its text value, such as the location at which the token occurs in the field. Because a tokenizer may produce tokens that diverge from the input text, you should not assume that the text of the token is the same text that occurs in the field, or that its length is the same as the original text. It's also possible for more than one token to have the same position or refer to the same offset in the original text. Keep this in mind if you use token metadata for things like highlighting search results in the field text.
+
+[source,xml]
+----
+<fieldType name="text" class="solr.TextField">
+  <analyzer>
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+  </analyzer>
+</fieldType>
+----
+
+The class named in the tokenizer element is not the actual tokenizer, but rather a class that implements the `TokenizerFactory` API. This factory class will be called upon to create new tokenizer instances as needed. Objects created by the factory must derive from `Tokenizer`, which indicates that they produce sequences of tokens. If the tokenizer produces tokens that are usable as is, it may be the only component of the analyzer. Otherwise, the tokenizer's output tokens will serve as input to the first filter stage in the pipeline.
+
+A `TypeTokenFilterFactory` is available that creates a `TypeTokenFilter` that filters tokens based on their TypeAttribute, which is set in `factory.getStopTypes`.
+
+For a complete list of the available TokenFilters, see the section <<tokenizers.adoc#tokenizers,Tokenizers>>.
+
+[[AboutTokenizers-WhenTouseaCharFiltervs.aTokenFilter]]
+== When To use a CharFilter vs. a TokenFilter
+
+There are several pairs of CharFilters and TokenFilters that have related (ie: `MappingCharFilter` and `ASCIIFoldingFilter`) or nearly identical (ie: `PatternReplaceCharFilterFactory` and `PatternReplaceFilterFactory`) functionality and it may not always be obvious which is the best choice.
+
+The decision about which to use depends largely on which Tokenizer you are using, and whether you need to preprocess the stream of characters.
+
+For example, suppose you have a tokenizer such as `StandardTokenizer` and although you are pretty happy with how it works overall, you want to customize how some specific characters behave. You could modify the rules and re-build your own tokenizer with JFlex, but it might be easier to simply map some of the characters before tokenization with a `CharFilter`.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc b/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
new file mode 100644
index 0000000..4c6a04d
--- /dev/null
+++ b/solr/solr-ref-guide/src/adding-custom-plugins-in-solrcloud-mode.adoc
@@ -0,0 +1,156 @@
+= Adding Custom Plugins in SolrCloud Mode
+:page-shortname: adding-custom-plugins-in-solrcloud-mode
+:page-permalink: adding-custom-plugins-in-solrcloud-mode.html
+
+In SolrCloud mode, custom plugins need to be shared across all nodes of the cluster.
+
+When running Solr in SolrCloud mode and you want to use custom code (such as custom analyzers, tokenizers, query parsers, and other plugins), it can be cumbersome to add jars to the classpath on all nodes in your cluster. Using the <<blob-store-api.adoc#blob-store-api,Blob Store API>> and special commands with the <<config-api.adoc#config-api,Config API>>, you can upload jars to a special system-level collection and dynamically load plugins from them at runtime with out needing to restart any nodes.
+
+.This Feature is Disabled By Default
+[IMPORTANT]
+====
+In addition to requiring that Solr by running in <<solrcloud.adoc#solrcloud,SolrCloud>> mode, this feature is also disabled by default unless all Solr nodes are run with the `-Denable.runtime.lib=true` option on startup.
+
+Before enabling this feature, users should carefully consider the issues discussed in the <<Securing Runtime Libraries>> section below.
+====
+
+[[AddingCustomPluginsinSolrCloudMode-UploadingJarFiles]]
+== Uploading Jar Files
+
+The first step is to use the <<blob-store-api.adoc#blob-store-api,Blob Store API>> to upload your jar files. This will to put your jars in the `.system` collection and distribute them across your SolrCloud nodes. These jars are added to a separate classloader and only accessible to components that are configured with the property `runtimeLib=true`. These components are loaded lazily because the `.system` collection may not be loaded when a particular core is loaded.
+
+[[AddingCustomPluginsinSolrCloudMode-ConfigAPICommandstouseJarsasRuntimeLibraries]]
+== Config API Commands to use Jars as Runtime Libraries
+
+The runtime library feature uses a special set of commands for the <<config-api.adoc#config-api,Config API>> to add, update, or remove jar files currently available in the blob store to the list of runtime libraries.
+
+The following commands are used to manage runtime libs:
+
+* `add-runtimelib`
+* `update-runtimelib`
+* `delete-runtimelib`
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+   "add-runtimelib": { "name":"jarblobname", "version":2 },
+   "update-runtimelib": { "name":"jarblobname", "version":3 },
+   "delete-runtimelib": "jarblobname"
+}'
+----
+
+The name to use is the name of the blob that you specified when you uploaded your jar to the blob store. You should also include the version of the jar found in the blob store that you want to use. These details are added to `configoverlay.json`.
+
+The default `SolrResourceLoader` does not have visibility to the jars that have been defined as runtime libraries. There is a classloader that can access these jars which is made available only to those components which are specially annotated.
+
+Every pluggable component can have an optional extra attribute called `runtimeLib=true`, which means that the components are not loaded at core load time. Instead, they will be loaded on demand. If all the dependent jars are not available when the component is loaded, an error is thrown.
+
+This example shows creating a ValueSourceParser using a jar that has been loaded to the Blob store.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+  "create-valuesourceparser": {
+    "name": "nvl",
+    "runtimeLib": true,
+    "class": "solr.org.apache.solr.search.function.NvlValueSourceParser,
+    "nvlFloatValue": 0.0 }
+}'
+----
+
+[[AddingCustomPluginsinSolrCloudMode-SecuringRuntimeLibraries]]
+== Securing Runtime Libraries
+
+A drawback of this feature is that it could be used to load malicious executable code into the system. However, it is possible to restrict the system to load only trusted jars using http://en.wikipedia.org/wiki/Public_key_infrastructure[PKI] to verify that the executables loaded into the system are trustworthy.
+
+The following steps will allow you enable security for this feature. The instructions assume you have started all your Solr nodes with the `-Denable.runtime.lib=true`.
+
+[[Step1_GenerateanRSAPrivateKey]]
+=== Step 1: Generate an RSA Private Key
+
+The first step is to generate an RSA private key. The example below uses a 512-bit key, but you should use the strength appropriate to your needs.
+
+[source,bash]
+----
+$ openssl genrsa -out priv_key.pem 512
+----
+
+[[Step2_OutputthePublicKey]]
+=== Step 2: Output the Public Key
+
+The public portion of the key should be output in DER format so Java can read it.
+
+[source,bash]
+----
+$ openssl rsa -in priv_key.pem -pubout -outform DER -out pub_key.der
+----
+
+[[Step3_LoadtheKeytoZooKeeper]]
+=== Step 3: Load the Key to ZooKeeper
+
+The `.der` files that are output from Step 2 should then be loaded to ZooKeeper under a node `/keys/exe` so they are available throughout every node. You can load any number of public keys to that node and all are valid. If a key is removed from the directory, the signatures of that key will cease to be valid. So, before removing the a key, make sure to update your runtime library configurations with valid signatures with the `update-runtimelib` command.
+
+At the current time, you can only use the ZooKeeper `zkCli.sh` (or `zkCli.cmd` on Windows) script to issue these commands (the Solr version has the same name, but is not the same). If you have your own ZooKeeper ensemble running already, you can find the script in `$ZK_INSTALL/bin/zkCli.sh` (or `zkCli.cmd` if you are using Windows).
+
+NOTE: If you are running the embedded ZooKeeper that is included with Solr, you *do not* have this script already; in order to use it, you will need to download a copy of ZooKeeper v3.4.6 from http://zookeeper.apache.org/. Don't worry about configuring the download, you're just trying to get the command line utility script. When you start the script, you will connect to the embedded ZooKeeper.
+
+To load the keys, you will need to connect to ZooKeeper with `zkCli.sh`, create the directories, and then create the key file, as in the following example.
+
+[source,bash]
+----
+# Connect to ZooKeeper
+# Replace the server location below with the correct ZooKeeper connect string for your installation.
+$ .bin/zkCli.sh -server localhost:9983
+
+# After connection, you will interact with the ZK prompt.
+# Create the directories
+[zk: localhost:9983(CONNECTED) 5] create /keys
+[zk: localhost:9983(CONNECTED) 5] create /keys/exe
+
+# Now create the public key file in ZooKeeper
+# The second path is the path to the .der file on your local machine
+[zk: localhost:9983(CONNECTED) 5] create /keys/exe/pub_key.der /myLocal/pathTo/pub_key.der
+----
+
+After this, any attempt to load a jar will fail. All your jars must be signed with one of your private keys for Solr to trust it. The process to sign your jars and use the signature is outlined in Steps 4-6.
+
+[[Step4_SignthejarFile]]
+=== Step 4: Sign the jar File
+
+Next you need to sign the sha1 digest of your jar file and get the base64 string.
+
+[source,bash]
+----
+$ openssl dgst -sha1 -sign priv_key.pem myjar.jar | openssl enc -base64
+----
+
+The output of this step will be a string that you will need to add the jar to your classpath in Step 6 below.
+
+[[Step5_LoadthejartotheBlobStore]]
+=== Step 5: Load the jar to the Blob Store
+
+Load your jar to the Blob store, using the <<blob-store-api.adoc#blob-store-api,Blob Store API>>. This step does not require a signature; you will need the signature in Step 6 to add it to your classpath.
+
+[source,bash]
+----
+curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @{filename}
+http://localhost:8983/solr/.system/blob/{blobname}
+----
+
+The blob name that you give the jar file in this step will be used as the name in the next step.
+
+[[Step6_AddthejartotheClasspath]]
+=== Step 6: Add the jar to the Classpath
+
+Finally, add the jar to the classpath using the Config API as detailed above. In this step, you will need to provide the signature of the jar that you got in Step 4.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json'  -d '{
+  "add-runtimelib": {
+    "name":"blobname",
+    "version":2,
+    "sig":"mW1Gwtz2QazjfVdrLFHfbGwcr8xzFYgUOLu68LHqWRDvLG0uLcy1McQ+AzVmeZFBf1yLPDEHBWJb5KXr8bdbHN/
+           PYgUB1nsr9pk4EFyD9KfJ8TqeH/ijQ9waa/vjqyiKEI9U550EtSzruLVZ32wJ7smvV0fj2YYhrUaaPzOn9g0=" }
+}'
+----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/analysis-screen.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/analysis-screen.adoc b/solr/solr-ref-guide/src/analysis-screen.adoc
new file mode 100644
index 0000000..2910206
--- /dev/null
+++ b/solr/solr-ref-guide/src/analysis-screen.adoc
@@ -0,0 +1,17 @@
+= Analysis Screen
+:page-shortname: analysis-screen
+:page-permalink: analysis-screen.html
+
+The Analysis screen lets you inspect how data will be handled according to the field, field type and dynamic field configurations found in your Schema. You can analyze how content would be handled during indexing or during query processing and view the results separately or at the same time. Ideally, you would want content to be handled consistently, and this screen allows you to validate the settings in the field type or field analysis chains.
+
+Enter content in one or both boxes at the top of the screen, and then choose the field or field type definitions to use for analysis.
+
+image::images/analysis-screen/analysis_normal.png[image,height=400]
+
+If you click the *Verbose Output* check box, you see more information, including more details on the transformations to the input (such as, convert to lower case, strip extra characters, etc.) including the raw bytes, type and detailed position information at each stage. The information displayed will vary depending on the settings of the field or field type. Each step of the process is displayed in a separate section, with an abbreviation for the tokenizer or filter that is applied in that step. Hover or click on the abbreviation, and you'll see the name and path of the tokenizer or filter.
+
+image::images/analysis-screen/analysis_verbose.png[image,height=400]
+
+In the example screenshot above, several transformations are applied to the input "Running is a sport." The words "is" and "a" have been removed and the word "running" has been changed to its basic form, "run". This is because we are using the field type `text_en` in this scenario, which is configured to remove stop words (small words that usually do not provide a great deal of context) and "stem" terms when possible to find more possible matches (this is particularly helpful with plural forms of words). If you click the question mark next to the *Analyze Fieldname/Field Type* pull-down menu, the <<schema-browser-screen.adoc#schema-browser-screen,Schema Browser window>> will open, showing you the settings for the field specified.
+
+The section <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,Understanding Analyzers, Tokenizers, and Filters>> describes in detail what each option is and how it may transform your data and the section <<running-your-analyzer.adoc#running-your-analyzer,Running Your Analyzer>> has specific examples for using the Analysis screen.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/analyzers.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/analyzers.adoc b/solr/solr-ref-guide/src/analyzers.adoc
new file mode 100644
index 0000000..6753737
--- /dev/null
+++ b/solr/solr-ref-guide/src/analyzers.adoc
@@ -0,0 +1,103 @@
+= Analyzers
+:page-shortname: analyzers
+:page-permalink: analyzers.html
+
+An analyzer examines the text of fields and generates a token stream.
+
+Analyzers are specified as a child of the `<fieldType>` element in the `schema.xml` configuration file (in the same `conf/` directory as `solrconfig.xml`).
+
+In normal usage, only fields of type `solr.TextField` will specify an analyzer. The simplest way to configure an analyzer is with a single `<analyzer>` element whose class attribute is a fully qualified Java class name. The named class must derive from `org.apache.lucene.analysis.Analyzer`. For example:
+
+[source,xml]
+----
+<fieldType name="nametext" class="solr.TextField">
+  <analyzer class="org.apache.lucene.analysis.core.WhitespaceAnalyzer"/>
+</fieldType>
+----
+
+In this case a single class, `WhitespaceAnalyzer`, is responsible for analyzing the content of the named text field and emitting the corresponding tokens. For simple cases, such as plain English prose, a single analyzer class like this may be sufficient. But it's often necessary to do more complex analysis of the field content.
+
+Even the most complex analysis requirements can usually be decomposed into a series of discrete, relatively simple processing steps. As you will soon discover, the Solr distribution comes with a large selection of tokenizers and filters that covers most scenarios you are likely to encounter. Setting up an analyzer chain is very straightforward; you specify a simple `<analyzer>` element (no class attribute) with child elements that name factory classes for the tokenizer and filters to use, in the order you want them to run.
+
+For example:
+
+[source,xml]
+----
+<fieldType name="nametext" class="solr.TextField">
+  <analyzer>
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.StandardFilterFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+    <filter class="solr.StopFilterFactory"/>
+    <filter class="solr.EnglishPorterFilterFactory"/>
+  </analyzer>
+</fieldType>
+----
+
+Note that classes in the `org.apache.solr.analysis` package may be referred to here with the shorthand `solr.` prefix.
+
+In this case, no Analyzer class was specified on the `<analyzer>` element. Rather, a sequence of more specialized classes are wired together and collectively act as the Analyzer for the field. The text of the field is passed to the first item in the list (`solr.StandardTokenizerFactory`), and the tokens that emerge from the last one (`solr.EnglishPorterFilterFactory`) are the terms that are used for indexing or querying any fields that use the "nametext" `fieldType`.
+
+.Field Values versus Indexed Terms
+[IMPORTANT]
+====
+The output of an Analyzer affects the _terms_ indexed in a given field (and the terms used when parsing queries against those fields) but it has no impact on the _stored_ value for the fields. For example: an analyzer might split "Brown Cow" into two indexed terms "brown" and "cow", but the stored value will still be a single String: "Brown Cow"
+====
+
+[[Analyzers-AnalysisPhases]]
+== Analysis Phases
+
+Analysis takes place in two contexts. At index time, when a field is being created, the token stream that results from analysis is added to an index and defines the set of terms (including positions, sizes, and so on) for the field. At query time, the values being searched for are analyzed and the terms that result are matched against those that are stored in the field's index.
+
+In many cases, the same analysis should be applied to both phases. This is desirable when you want to query for exact string matches, possibly with case-insensitivity, for example. In other cases, you may want to apply slightly different analysis steps during indexing than those used at query time.
+
+If you provide a simple `<analyzer>` definition for a field type, as in the examples above, then it will be used for both indexing and queries. If you want distinct analyzers for each phase, you may include two `<analyzer>` definitions distinguished with a type attribute. For example:
+
+[source,xml]
+----
+<fieldType name="nametext" class="solr.TextField">
+  <analyzer type="index">
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+    <filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/>
+    <filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/>
+  </analyzer>
+  <analyzer type="query">
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+  </analyzer>
+</fieldType>
+----
+
+In this theoretical example, at index time the text is tokenized, the tokens are set to lowercase, any that are not listed in `keepwords.txt` are discarded and those that remain are mapped to alternate values as defined by the synonym rules in the file `syns.txt`. This essentially builds an index from a restricted set of possible values and then normalizes them to values that may not even occur in the original text.
+
+At query time, the only normalization that happens is to convert the query terms to lowercase. The filtering and mapping steps that occur at index time are not applied to the query terms. Queries must then, in this example, be very precise, using only the normalized terms that were stored at index time.
+
+[[Analyzers-AnalysisforMulti-TermExpansion]]
+=== Analysis for Multi-Term Expansion
+
+In some types of queries (ie: Prefix, Wildcard, Regex, etc...) the input provided by the user is not natural language intended for Analysis. Things like Synonyms or Stop word filtering do not work in a logical way in these types of Queries.
+
+The analysis factories that _can_ work in these types of queries (such as Lowercasing, or Normalizing Factories) are known as {lucene-javadocs}/analyzers-common/org/apache/lucene/analysis/util/MultiTermAwareComponent.html[`MultiTermAwareComponents`]. When Solr needs to perform analysis for a query that results in Multi-Term expansion, only the `MultiTermAwareComponents` used in the `query` analyzer are used, Factory that is not Multi-Term aware will be skipped.
+
+For most use cases, this provides the best possible behavior, but if you wish for absolute control over the analysis performed on these types of queries, you may explicitly define a `multiterm` analyzer to use, such as in the following example:
+
+[source,xml]
+----
+<fieldType name="nametext" class="solr.TextField">
+  <analyzer type="index">
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+    <filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/>
+    <filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/>
+  </analyzer>
+  <analyzer type="query">
+    <tokenizer class="solr.StandardTokenizerFactory"/>
+    <filter class="solr.LowerCaseFilterFactory"/>
+  </analyzer>
+  <!-- No analysis at all when doing queries that involved Multi-Term expansion -->
+  <analyzer type="multiterm">
+    <tokenizer class="solr.KeywordTokenizerFactory" />
+  </analyzer>
+</fieldType>
+----

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
new file mode 100644
index 0000000..2db6fee
--- /dev/null
+++ b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
@@ -0,0 +1,170 @@
+= Authentication and Authorization Plugins
+:page-shortname: authentication-and-authorization-plugins
+:page-permalink: authentication-and-authorization-plugins.html
+:page-children: basic-authentication-plugin, hadoop-authentication-plugin, kerberos-authentication-plugin, rule-based-authorization-plugin
+
+Solr has security frameworks for supporting authentication and authorization of users. This allows for verifying a user's identity and for restricting access to resources in a Solr cluster.
+
+Solr includes some plugins out of the box, and additional plugins can be developed using the authentication and authorization frameworks described below.
+
+All authentication and authorization plugins can work with Solr whether they are running in SolrCloud mode or standalone mode. All authentication and authorization configuration, including users and permission rules, are stored in a file named `security.json`. When using Solr in standalone mode, this file must be in the `$SOLR_HOME` directory (usually `server/solr`). When using SolrCloud, this file must be located in ZooKeeper.
+
+The following section describes how to enable plugins with `security.json` and place them in the proper locations for your mode of operation.
+
+[[AuthenticationandAuthorizationPlugins-EnablePluginswithsecurity.json]]
+== Enable Plugins with security.json
+
+All of the information required to initialize either type of security plugin is stored in a `security.json` file. This file contains 2 sections, one each for authentication and authorization.
+
+.Sample security.json
+[source,json]
+----
+{
+  "authentication" : {
+    "class": "class.that.implements.authentication"
+  },
+  "authorization": {
+    "class": "class.that.implements.authorization"
+  }
+}
+----
+
+The `/security.json` file needs to be in the proper location before a Solr instance comes up so Solr starts with the security plugin enabled. See the section <<AuthenticationandAuthorizationPlugins-Usingsecurity.jsonwithSolr,Using security.json with Solr>> below for information on how to do this.
+
+Depending on the plugin(s) in use, other information will be stored in `security.json` such as user information or rules to create roles and permissions. This information is added through the APIs for each plugin provided by Solr, or, in the case of a custom plugin, the approach designed by you.
+
+Here is a more detailed `security.json` example. In this, the Basic authentication and rule-based authorization plugins are enabled, and some data has been added:
+
+[source,json]
+----
+{
+"authentication":{
+   "class":"solr.BasicAuthPlugin",
+   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
+},
+"authorization":{
+   "class":"solr.RuleBasedAuthorizationPlugin",
+   "permissions":[{"name":"security-edit",
+      "role":"admin"}],
+   "user-role":{"solr":"admin"}
+}}
+----
+
+[[AuthenticationandAuthorizationPlugins-Usingsecurity.jsonwithSolr]]
+== Using security.json with Solr
+
+[[AuthenticationandAuthorizationPlugins-InSolrCloudmode]]
+=== In SolrCloud Mode
+
+While configuring Solr to use an authentication or authorization plugin, you will need to upload a `security.json` file to ZooKeeper. The following command writes the file as it uploads it - you could also upload a file that you have already created locally.
+
+[source,bash]
+----
+>server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put /security.json
+  '{"authentication": {"class": "org.apache.solr.security.KerberosPlugin"}}'
+----
+
+Note that this example defines the `KerberosPlugin` for authentication. You will want to modify this section as appropriate for the plugin you are using.
+
+This example also defines `security.json` on the command line, but you can also define a file locally and upload it to ZooKeeper.
+
+[WARNING]
+====
+Depending on the authentication and authorization plugin that you use, you may have user information stored in `security.json`. If so, we highly recommend that you implement access control in your ZooKeeper nodes. Information about how to enable this is available in the section <<zookeeper-access-control.adoc#zookeeper-access-control,ZooKeeper Access Control>>.
+====
+
+Once `security.json` has been uploaded to ZooKeeper, you should use the appropriate APIs for the plugins you're using to update it. You can edit it manually, but you must take care to remove any version data so it will be properly updated across all ZooKeeper nodes. The version data is found at the end of the `security.json` file, and will appear as the letter "v" followed by a number, such as `{"v":138}`.
+
+[[AuthenticationandAuthorizationPlugins-InStandaloneMode]]
+=== In Standalone Mode
+
+When running Solr in standalone mode, you need to create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`).
+
+If you are using <<legacy-scaling-and-distribution.adoc#legacy-scaling-and-distribution,Legacy Scaling and Distribution>>, you will need to place `security.json` on each node of the cluster.
+
+You can use the authentication and authorization APIs, but if you are using the legacy scaling model, you will need to make the same API requests on each node separately. You can also edit `security.json` by hand if you prefer.
+
+[[AuthenticationandAuthorizationPlugins-Authentication]]
+== Authentication
+
+Authentication plugins help in securing the endpoints of Solr by authenticating incoming requests. A custom plugin can be implemented by extending the AuthenticationPlugin class.
+
+An authentication plugin consists of two parts:
+
+. Server-side component, which intercepts and authenticates incoming requests to Solr using a mechanism defined in the plugin, such as Kerberos, Basic Auth or others.
+. Client-side component, i.e., an extension of `HttpClientConfigurer`, which enables a SolrJ client to make requests to a secure Solr instance using the authentication mechanism which the server understands.
+
+[[AuthenticationandAuthorizationPlugins-EnablingaPlugin]]
+=== Enabling a Plugin
+
+* Specify the authentication plugin in `/security.json` as in this example:
++
+[source,json]
+----
+{
+  "authentication": {
+    "class": "class.that.implements.authentication",
+    "other_data" : "..."}
+}
+----
+* All of the content in the authentication block of `security.json` would be passed on as a map to the plugin during initialization.
+* An authentication plugin can also be used with a standalone Solr instance by passing in `-DauthenticationPlugin=<plugin class name>` during startup.
+
+[[AuthenticationandAuthorizationPlugins-AvailableAuthenticationPlugins]]
+=== Available Authentication Plugins
+
+Solr has the following implementations of authentication plugins:
+
+* <<kerberos-authentication-plugin.adoc#kerberos-authentication-plugin,Kerberos Authentication Plugin>>
+* <<basic-authentication-plugin.adoc#basic-authentication-plugin,Basic Authentication Plugin>>
+* <<hadoop-authentication-plugin.adoc#hadoop-authentication-plugin,Hadoop Authentication Plugin>>
+
+[[AuthenticationandAuthorizationPlugins-Authorization]]
+== Authorization
+
+An authorization plugin can be written for Solr by extending the {solr-javadocs}/solr-core/org/apache/solr/security/AuthorizationPlugin.html[AuthorizationPlugin] interface.
+
+[[AuthenticationandAuthorizationPlugins-LoadingaCustomPlugin]]
+=== Loading a Custom Plugin
+
+* Make sure that the plugin implementation is in the classpath.
+* The plugin can then be initialized by specifying the same in `security.json` in the following manner:
+
+[source,json]
+----
+{
+  "authorization": {
+    "class": "org.apache.solr.security.MockAuthorizationPlugin",
+    "other_data" : "..."}
+}
+----
+
+All of the content in the `authorization` block of `security.json` would be passed on as a map to the plugin during initialization.
+
+[IMPORTANT]
+====
+The authorization plugin is only supported in SolrCloud mode. Also, reloading the plugin isn't yet supported and requires a restart of the Solr installation (meaning, the JVM should be restarted, not simply a core reload).
+====
+
+[[AuthenticationandAuthorizationPlugins-AvailableAuthorizationPlugins]]
+=== Available Authorization Plugins
+
+Solr has one implementation of an authorization plugin:
+
+* <<rule-based-authorization-plugin.adoc#rule-based-authorization-plugin,Rule-Based Authorization Plugin>>
+
+[[AuthenticationandAuthorizationPlugins-PKISecuringInter-NodeRequests]]
+
+[[AuthenticationandAuthorizationPlugins-PKI]]
+== Securing Inter-Node Requests
+
+There are a lot of requests that originate from the Solr nodes itself. For example, requests from overseer to nodes, recovery threads, etc. Each Authentication plugin declares whether it is capable of securing inter-node requests or not. If not, Solr will fall back to using a special internode authentication mechanism where each Solr node is a super user and is fully trusted by other Solr nodes, described below.
+
+[[AuthenticationandAuthorizationPlugins-PKIAuthenticationPlugin]]
+=== PKIAuthenticationPlugin
+
+The PKIAuthenticationPlugin is used when there is any request going on between two Solr nodes, and the configured Authentication plugin does not wish to handle inter-node security.
+
+For each outgoing request `PKIAuthenticationPlugin` adds a special header `'SolrAuth'` which carries the timestamp and principal encrypted using the private key of that node. The public key is exposed through an API so that any node can read it whenever it needs it. Any node who gets the request with that header, would get the public key from the sender and decrypt the information. If it is able to decrypt the data, the request trusted. It is invalid if the timestamp is more than 5 secs old. This assumes that the clocks of different nodes in the cluster are synchronized.
+
+The timeout is configurable through a system property called `pkiauth.ttl`. For example, if you wish to bump up the time-to-live to 10 seconds (10000 milliseconds), start each node with a property `'-Dpkiauth.ttl=10000'`.

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/95968c69/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
new file mode 100644
index 0000000..592da1b
--- /dev/null
+++ b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
@@ -0,0 +1,140 @@
+= Basic Authentication Plugin
+:page-shortname: basic-authentication-plugin
+:page-permalink: basic-authentication-plugin.html
+
+Solr can support Basic authentication for users with the use of the BasicAuthPlugin.
+
+An authorization plugin is also available to configure Solr with permissions to perform various activities in the system. The authorization plugin is described in the section <<rule-based-authorization-plugin.adoc#rule-based-authorization-plugin,Rule-Based Authorization Plugin>>.
+
+[[BasicAuthenticationPlugin-EnableBasicAuthentication]]
+== Enable Basic Authentication
+
+To use Basic authentication, you must first create a `security.json` file. This file and where to put it is described in detail in the section <<authentication-and-authorization-plugins.adoc#AuthenticationandAuthorizationPlugins-EnablePluginswithsecurity.json,Enable Plugins with security.json>>.
+
+For Basic authentication, the `security.json` file must have an `authentication` part which defines the class being used for authentication. Usernames and passwords (as a sha256(password+salt) hash) could be added when the file is created, or can be added later with the Basic authentication API, described below.
+
+The `authorization` part is not related to Basic authentication, but is a separate authorization plugin designed to support fine-grained user access control. For more information, see the section <<rule-based-authorization-plugin.adoc#rule-based-authorization-plugin,Rule-Based Authorization Plugin>>.
+
+An example `security.json` showing both sections is shown below to show how these plugins can work together:
+
+[source,json]
+----
+{
+"authentication":{
+   "blockUnknown": true,
+   "class":"solr.BasicAuthPlugin",
+   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
+},
+"authorization":{
+   "class":"solr.RuleBasedAuthorizationPlugin",
+   "permissions":[{"name":"security-edit",
+      "role":"admin"}],
+   "user-role":{"solr":"admin"}
+}}
+----
+
+There are several things defined in this file:
+
+* Basic authentication and rule-based authorization plugins are enabled.
+* A user called 'solr', with a password `'SolrRocks'` has been defined.
+* The parameter `"blockUnknown": true` means that unauthenticated requests are not allowed to pass through.
+* The 'admin' role has been defined, and it has permission to edit security settings.
+* The 'solr' user has been defined to the 'admin' role.
+
+Save your settings to a file called `security.json` locally. If you are using Solr in standalone mode, you should put this file in `$SOLR_HOME`.
+
+If `blockUnknown` does not appear in the `security.json` file, it will default to `false`. This has the effect of not requiring authentication at all. In some cases, you may want this; for example, if you want to have `security.json` in place but aren't ready to enable authentication. However, you will want to ensure that this parameter is set to `true` in order for authentication to be truly enabled in your system.
+
+If you are using SolrCloud, you must upload `security.json` to ZooKeeper. You can use this example command, ensuring that the ZooKeeper port is correct:
+
+[source,bash]
+----
+bin/solr zk cp file:path_to_local_security.json zk:/security.json -z localhost:9983
+----
+
+[[BasicAuthenticationPlugin-Caveats]]
+=== Caveats
+
+There are a few things to keep in mind when using the Basic authentication plugin.
+
+* Credentials are sent in plain text by default. It's recommended to use SSL for communication when Basic authentication is enabled, as described in the section <<enabling-ssl.adoc#enabling-ssl,Enabling SSL>>.
+* A user who has access to write permissions to `security.json` will be able to modify all the permissions and how users have been assigned permissions. Special care should be taken to only grant access to editing security to appropriate users.
+* Your network should, of course, be secure. Even with Basic authentication enabled, you should not unnecessarily expose Solr to the outside world.
+
+[[BasicAuthenticationPlugin-EditingAuthenticationPluginConfiguration]]
+== Editing Authentication Plugin Configuration
+
+An Authentication API allows modifying user IDs and passwords. The API provides an endpoint with specific commands to set user details or delete a user.
+
+[[BasicAuthenticationPlugin-APIEntryPoint]]
+=== API Entry Point
+
+`admin/authentication`
+
+This endpoint is not collection-specific, so users are created for the entire Solr cluster. If users need to be restricted to a specific collection, that can be done with the authorization rules.
+
+[[BasicAuthenticationPlugin-AddaUserorEditaPassword]]
+=== Add a User or Edit a Password
+
+The `set-user` command allows you to add users and change their passwords. For example, the following defines two users and their passwords:
+
+[source,bash]
+----
+curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d '{
+  "set-user": {"tom" : "TomIsCool" ,
+               "harry":"HarrysSecret"}}'
+----
+
+[[BasicAuthenticationPlugin-DeleteaUser]]
+=== Delete a User
+
+The `delete-user` command allows you to remove a user. The user password does not need to be sent to remove a user. In the following example, we've asked that user IDs 'tom' and 'harry' be removed from the system.
+
+[source,bash]
+----
+curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d  '{
+ "delete-user": ["tom","harry"]}'
+----
+
+[[BasicAuthenticationPlugin-Setaproperty]]
+=== Set a property
+
+Set arbitrary properties for authentication plugin. The only supported property is `'blockUnknown'`
+
+[source,bash]
+----
+curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d  '{
+ "set-property": {"blockUnknown":false}}'
+----
+
+[[BasicAuthenticationPlugin-UsingBasicAuthwithSolrJ]]
+=== Using BasicAuth with SolrJ
+
+In SolrJ, the basic authentication credentials need to be set for each request as in this example:
+
+[source,java]
+----
+SolrRequest req ;//create a new request object
+req.setBasicAuthCredentials(userName, password);
+solrClient.request(req);
+----
+
+Query example:
+
+[source,java]
+----
+QueryRequest req = new QueryRequest(new SolrQuery("*:*"));
+req.setBasicAuthCredentials(userName, password);
+QueryResponse rsp = req.process(solrClient);
+----
+
+[[BasicAuthenticationPlugin-UsingCommandLinescriptswithBasicAuth]]
+=== Using Command Line scripts with BasicAuth
+
+Add the following line to the `solr.in.sh` or `solr.in.cmd` file. This example tells the `bin/solr` command line to to use "basic" as the type of authentication, and to pass credentials with the user-name "solr" and password "SolrRocks":
+
+[source,bash]
+----
+SOLR_AUTH_TYPE="basic"
+SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:SolrRocks"
+----