You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by dw...@apache.org on 2021/03/10 09:59:57 UTC
[lucene] 44/50: Ref Guide: parameterize versions in
using-solrj.adoc and move autoscaling api docs in hierarchy
This is an automated email from the ASF dual-hosted git repository.
dweiss pushed a commit to branch branch_7_1
in repository https://gitbox.apache.org/repos/asf/lucene.git
commit c104bd66850fc8d45134d93a1c52b8a1136710d2
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Fri Oct 27 10:39:07 2017 -0500
Ref Guide: parameterize versions in using-solrj.adoc and move autoscaling api docs in hierarchy
---
solr/solr-ref-guide/src/solrcloud-autoscaling.adoc | 4 ++--
solr/solr-ref-guide/src/using-solrj.adoc | 26 +++++++++++-----------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
index 0bebed84..b9a66fd 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling.adoc
@@ -1,7 +1,7 @@
= SolrCloud Autoscaling
:page-shortname: solrcloud-autoscaling
:page-permalink: solrcloud-autoscaling.html
-:page-children: solrcloud-autoscaling-overview, solrcloud-autoscaling-api, solrcloud-autoscaling-policy-preferences, solrcloud-autoscaling-triggers, solrcloud-autoscaling-trigger-actions, solrcloud-autoscaling-listeners, solrcloud-autoscaling-auto-add-replicas, solrcloud-autoscaling-fault-tolerance
+:page-children: solrcloud-autoscaling-overview, solrcloud-autoscaling-policy-preferences, solrcloud-autoscaling-triggers, solrcloud-autoscaling-trigger-actions, solrcloud-autoscaling-listeners, solrcloud-autoscaling-auto-add-replicas, solrcloud-autoscaling-fault-tolerance, solrcloud-autoscaling-api
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
@@ -27,10 +27,10 @@ Autoscaling includes an API to manage cluster-wide and collection-specific polic
The following sections describe the autoscaling features of SolrCloud:
* <<solrcloud-autoscaling-overview.adoc#solrcloud-autoscaling-overview,Overview of Autoscaling in SolrCloud>>
-* <<solrcloud-autoscaling-api.adoc#solrcloud-autoscaling-api,Autoscaling API>>
* <<solrcloud-autoscaling-policy-preferences.adoc#solrcloud-autoscaling-policy-preferences,Autoscaling Policy and Preferences>>
* <<solrcloud-autoscaling-triggers.adoc#solrcloud-autoscaling-triggers,Autoscaling Triggers>>
* <<solrcloud-autoscaling-trigger-actions.adoc#solrcloud-autoscaling-trigger-actions,Autoscaling Trigger Actions>>
* <<solrcloud-autoscaling-listeners.adoc#solrcloud-autoscaling-listeners,Autoscaling Listeners>>
* <<solrcloud-autoscaling-auto-add-replicas.adoc#solrcloud-autoscaling-auto-add-replicas,Autoscaling - Automatically Adding Replicas>>
* <<solrcloud-autoscaling-fault-tolerance.adoc#solrcloud-autoscaling-fault-tolerance,Autoscaling Fault Tolerance>>
+* <<solrcloud-autoscaling-api.adoc#solrcloud-autoscaling-api,Autoscaling API>>
diff --git a/solr/solr-ref-guide/src/using-solrj.adoc b/solr/solr-ref-guide/src/using-solrj.adoc
index f3abaab..4a633ac 100644
--- a/solr/solr-ref-guide/src/using-solrj.adoc
+++ b/solr/solr-ref-guide/src/using-solrj.adoc
@@ -30,45 +30,45 @@ Most mainstream build systems greatly simplify dependency management, making it
For projects built with Ant (using http://ant.apache.org/ivy/[Ivy]), place the following in your `ivy.xml`:
-[source,xml]
+[source,xml,subs="verbatim,attributes"]
----
-<dependency org="org.apache.solr" name="solr-solrj" rev="x.y.z"/>
+<dependency org="org.apache.solr" name="solr-solrj" rev="{solr-docs-version}.0"/>
----
For projects built with Maven, place the following in your `pom.xml`:
-[source,xml]
+[source,xml,subs="verbatim,attributes"]
----
<dependency>
<groupId>org.apache.solr</groupId>
<artifactId>solr-solrj</artifactId>
- <version>x.y.z</version>
+ <version>{solr-docs-version}.0</version>
</dependency>
----
For projects built with Gradle, place the following in your `build.gradle`:
-[source,groovy]
+[source,groovy,subs="attributes"]
----
-compile group: 'org.apache.solr', name: 'solr-solrj', version: 'x.y.z'
+compile group: 'org.apache.solr', name: 'solr-solrj', version: '{solr-docs-version}.0'
----
=== Adding SolrJ to the Classpath Manually
If you are not using one of the above build system, it's still easy to add SolrJ to your build.
-At build time, all that is required is the SolrJ jar itself: `solr-solrj-x.y.z.jar`. To compile code manually that uses SolrJ, use a `javac` command similar to:
+At build time, all that is required is the SolrJ jar itself: `solr-solrj-{solr-docs-version}.0.jar`. To compile code manually that uses SolrJ, use a `javac` command similar to:
-[source,bash]
+[source,bash,subs="attributes"]
----
-javac -cp .:$SOLR_HOME/dist/solr-solrj-x.y.z.jar ...
+javac -cp .:$SOLR_HOME/dist/solr-solrj-{solr-docs-version}.0.jar ...
----
At runtime, you need a few of SolrJ's dependencies, in addition to SolrJ itself. For convenience, these dependencies are made available in the `dist/solrj-lib` directory. Run your project with a classpath like:
-[source,bash]
+[source,bash,subs="attributes"]
----
-java -cp .:$SOLR_HOME/dist/solrj-lib/*:$SOLR_HOME/dist/solr-solrj-x.y.z.jar ...
+java -cp .:$SOLR_HOME/dist/solrj-lib/*:$SOLR_HOME/dist/solr-solrj-{solr-docs-version}.0.jar ...
----
If you are worried about the SolrJ libraries expanding the size of your client application, you can use a code obfuscator like http://proguard.sourceforge.net/[ProGuard] to remove APIs that you are not using.
@@ -97,8 +97,8 @@ Most SolrJ configuration happens at the `SolrClient` level. The most common/imp
==== Base URLs
Most `SolrClient` implementations (with the notable exception of `CloudSolrClient`) require users to specify one or more Solr base URLs, which the client then uses to send HTTP requests to Solr. The path users include on the base URL they provide has an effect on the behavior of the created client from that point on.
-. A URL with a path pointing to a specific core or collection (e.g. `http://hostname:8983/solr/core1`). When a core or collection is specified in the base URL, subsequent requests made with that client are not required to re-specify the affected collection. However, the client is limited to sending requests to that core/collection, and can not send requests to any others.
-. A URL pointing to the root Solr path (e.g. `http://hostname:8983/solr`). When no core or collection is specified in the base URL, requests can be made to any core/collection, but the affected core/collection must be specified on all requests.
+. A URL with a path pointing to a specific core or collection (e.g., `http://hostname:8983/solr/core1`). When a core or collection is specified in the base URL, subsequent requests made with that client are not required to re-specify the affected collection. However, the client is limited to sending requests to that core/collection, and can not send requests to any others.
+. A URL pointing to the root Solr path (e.g., `http://hostname:8983/solr`). When no core or collection is specified in the base URL, requests can be made to any core/collection, but the affected core/collection must be specified on all requests.
Generally speaking, if your `SolrClient` will only be used on a single core/collection, including that entity in the path is the most convenient. Where more flexibility is required, the collection/core should be excluded.