This is an automated email from the ASF dual-hosted git repository.
janhoy pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/solr.git
The following commit(s) were added to refs/heads/main by this push:
new 372b293 Update the help folder for solr only (#6)
372b293 is described below
commit 372b293fe79f49f32f397ed75cad495caf055843
Author: Jan Høydahl <[email protected]>
AuthorDate: Wed Mar 10 22:52:26 2021 +0100
Update the help folder for solr only (#6)
---
help/ant.txt | 4 ++--
help/dependencies.txt | 14 +++++++-------
help/formatting.txt | 9 ++++++++-
help/jvms.txt | 2 +-
help/localSettings.txt | 4 ++--
help/tests.txt | 46 +++++++++++++++++++++++-----------------------
help/workflow.txt | 12 ++++++------
7 files changed, 49 insertions(+), 42 deletions(-)
diff --git a/help/ant.txt b/help/ant.txt
index 61a00ac..c62bb51 100644
--- a/help/ant.txt
+++ b/help/ant.txt
@@ -10,8 +10,8 @@ Gradle tasks apply to all modules that contain a given task
name. Use
"-p" switch with a directory or a colon-notation to specify a particular
task or module. For example these two are equivalent:
-gradlew -p lucene/core check
-gradlew :lucene:core:check
+gradlew -p solr/core check
+gradlew :solr:core:check
List of common dev task equivalents
-----------------------------------
diff --git a/help/dependencies.txt b/help/dependencies.txt
index 5db03c9..318b688 100644
--- a/help/dependencies.txt
+++ b/help/dependencies.txt
@@ -13,7 +13,7 @@
https://docs.gradle.org/current/userguide/dependency_management_for_java_project
https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation
https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management
-For the needs of Lucene and Solr we will typically focus on three
+For the needs of Solr we will typically focus on three
configurations and attach project dependencies to them:
api - makes a dependency available for main classes, tests and any
@@ -30,9 +30,9 @@ Adding a library dependency
---------------------------
Let's say we wish to add a dependency on library "foo.bar:baz" in
-version 1.2 to :lucene:core. Let's assume this library is only
-used internally by the project. The :lucene:core project is configured
-by lucene/core/build.gradle and we would add (or modify) the dependency
+version 1.2 to :solr:core. Let's assume this library is only
+used internally by the project. The :solr:core project is configured
+by solr/core/build.gradle and we would add (or modify) the dependency
block as follows:
dependencies {
@@ -90,7 +90,7 @@ Inspecting current dependencies
The tree of dependencies of a project (in all configurations) can
be dumped by the following command (example):
-gradlew -p lucene\analysis\icu dependencies
+gradlew -p solr/solrj dependencies
But this can be a bit overwhelming; we will most likely be interested
in just the "publicly visible" and "classpath-visible" configurations.
@@ -98,12 +98,12 @@ in just the "publicly visible" and "classpath-visible"
configurations.
The publicly visible project dependencies (classes shared by other
modules importing our module) can be displayed with:
-gradlew -p lucene\analysis\icu dependencies --configuration api
+gradlew -p solr/solrj dependencies --configuration api
And the "private" set of dependencies (real classpath) can be dumped
with:
-gradlew -p lucene\analysis\icu dependencies --configuration runtimeClasspath
+gradlew -p solr/solrj dependencies --configuration runtimeClasspath
Excluding a transitive dependency
diff --git a/help/formatting.txt b/help/formatting.txt
index 55490ac..96240b3f 100644
--- a/help/formatting.txt
+++ b/help/formatting.txt
@@ -1,7 +1,13 @@
Code formatting
===============
-Starting with (LUCENE-9564) Java code is enforced to comply with
+NOTE: This does not yet apply to Solr, see SOLR-14920 for details
+
+
+
+
+---
+Starting with (SOLR-14920) Java code is enforced to comply with
google-java-format conventions. In theory you shouldn't worry about
what the convention actually looks like - write the code in any way
you like and then run:
@@ -18,3 +24,4 @@ majority of cases the formatter will do a great job of
cleaning up the
code. Occasionally you may want to rewrite the code (introduce a local
variable orreshape code paths) so that it's easier to read after
automatic formatting.
+---
\ No newline at end of file
diff --git a/help/jvms.txt b/help/jvms.txt
index 42a88d2..3e14a8d 100644
--- a/help/jvms.txt
+++ b/help/jvms.txt
@@ -12,7 +12,7 @@ property (-P...).
Example:
-gradlew test -p lucene/test-framework --tests TestJvmInfo -Dtests.verbose=true
-Druntime.java.home=/jvms/jdk14
+gradlew test -p solr/test-framework --tests TestLogLevelAnnotations
-Dtests.verbose=true -Druntime.java.home=/jvms/jdk14
Note that an alternative JVM can also be made the "default" setting
by adding it to (project-local) gradle.properties.
diff --git a/help/localSettings.txt b/help/localSettings.txt
index 263af7f..1336497 100644
--- a/help/localSettings.txt
+++ b/help/localSettings.txt
@@ -1,7 +1,7 @@
Local developer settings
========================
-The first invocation of any task in Lucene/Solr gradle build will generate
+The first invocation of any task in Solr gradle build will generate
and save a project-local 'gradle.properties' file. This file contains
the defaults you may (but don't have to) tweak for your particular hardware
(or taste).
@@ -12,7 +12,7 @@ Parallelism
-----------
Gradle build can run tasks in parallel but by default it consumes all CPU
cores which
-is too optimistic a default for Lucene/Solr tests. You can disable the
parallelism
+is too optimistic a default for Solr tests. You can disable the parallelism
entirely or assign it a 'low' priority with these properties:
org.gradle.parallel=[true, false]
diff --git a/help/tests.txt b/help/tests.txt
index 5054c0e..2cbc847 100644
--- a/help/tests.txt
+++ b/help/tests.txt
@@ -23,8 +23,8 @@ gradlew check -x test
Run verification for a selected module only:
-gradlew :lucene:core:check # By full gradle project path
-gradlew -p lucene/core check # By folder designation + task
+gradlew :solr:core:check # By full gradle project path
+gradlew -p solr/core check # By folder designation + task
Randomization
@@ -33,35 +33,35 @@ Randomization
To run tests with the given starting seed pass 'tests.seed'
property:
-gradlew :lucene:misc:test -Ptests.seed=DEADBEEF
+gradlew :solr:solrj:test -Ptests.seed=DEADBEEF
There are a lot of other test randomization properties
available. To list them, their defaults and current values
run the testOpts task against a project that has tests.
For example:
-gradlew -p lucene/core testOpts
+gradlew -p solr/core testOpts
Filtering
---------
-Run tests of lucene-core module:
+Run tests of solr-core module:
-gradlew -p lucene/core test
+gradlew -p solr/core test
Run a single test case (from a single module). Uses gradle's built-in filtering
(https://docs.gradle.org/current/userguide/java_testing.html#test_filtering):
-gradlew -p lucene/core test --tests TestDemo
+gradlew -p solr/core test --tests TestDemo
Run all tests in a package:
-gradlew -p lucene/core test --tests "org.apache.lucene.document.*"
+gradlew -p solr/core test --tests "org.apache.solr.index.*"
Run all test classes/ methods that match this pattern:
-gradlew -p lucene/core test --tests "*testFeatureMissing*"
+gradlew -p solr/core test --tests "*RPTField*"
Test groups
@@ -72,13 +72,13 @@ Some test group annotations include: @AwaitsFix, @Nightly,
@Slow
This uses filtering infrastructure on the *runner* (randomizedtesting),
not gradle's built-in mechanisms (but it can be combined with "--tests").
-For example, run all lucene-core tests annotated as @Slow:
+For example, run all solr-core tests annotated as @Slow:
-gradlew -p lucene/core test -Ptests.filter=@Slow
+gradlew -p solr/core test -Ptests.filter=@Slow
Test group filters can be combined into Boolean expressions:
-gradlew -p lucene/core test "default and not(@awaitsfix or @slow)"
+gradlew -p solr/core test "default and not(@awaitsfix or @slow)"
Reiteration ("beasting")
@@ -87,19 +87,19 @@ Reiteration ("beasting")
Multiply each test case N times (this works by repeating the same test
within the same JVM; it also works in IDEs):
-gradlew -p lucene/core test --tests TestDemo -Ptests.iters=5
+gradlew -p solr/core test --tests TestDemo -Ptests.iters=5
Tests tasks will be (by default) re-executed on each invocation because
we pick a random global tests.seed. If you run the same tests twice
with the same seed, the test task will be skipped (as it is up-to-date
with respect to source code):
-gradlew -p lucene/core test -Ptests.seed=deadbeef
+gradlew -p solr/core test -Ptests.seed=deadbeef
to force re-execution of tests, even for the same master seed, apply
cleanTest task:
-gradlew -p lucene/core cleanTest test -Ptests.seed=deadbeef
+gradlew -p solr/core cleanTest test -Ptests.seed=deadbeef
The 'tests.iters' option should be sufficient for individual test cases
and is *much* faster than trying to duplicate re-runs of the entire
@@ -107,7 +107,7 @@ test suites. When it is absolutely needed to re-run an
entire suite (because
of randomization in the static initialization, for example), you can do it
by running the 'beast' task with 'tests.dups' option:
-gradlew -p lucene/core beast -Ptests.dups=10 --tests
TestPerFieldDocValuesFormat
+gradlew -p solr/core beast -Ptests.dups=10 --tests DummyMergePolicyFactory
Note the filter (--tests) used to narrow down test reiterations to a particular
class. You can use any filter, including no filter at all, but it rarely makes
@@ -115,7 +115,7 @@ sense (will take ages). By default the test tasks generated
by the 'beast' mode
use a random starting seed for randomization. If you pass an explicit seed,
this
won't be the case (all tasks will use exactly the same starting seed):
-gradlew -p lucene/core beast -Ptests.dups=10 --tests
TestPerFieldDocValuesFormat -Dtests.seed=deadbeef
+gradlew -p solr/core beast -Ptests.dups=10 --tests DummyMergePolicyFactory
-Dtests.seed=deadbeef
Verbose mode and debugging
--------------------------
@@ -124,7 +124,7 @@ The "tests.verbose" mode switch enables standard streams
from tests
to be dumped directly to the console. Run your verbose tests explicitly
specifying the project and test task or a fully qualified task path. Example:
-gradlew -p lucene/core test -Ptests.verbose=true --tests "TestDemo"
+gradlew -p solr/core test -Ptests.verbose=true --tests "TestDemo"
Profiling slow tests
@@ -135,23 +135,23 @@ and prints a simple summary at the end.
For example, top-10 histogram of methods (cpu samples):
-gradlew -p lucene/core test -Ptests.profile=true
+gradlew -p solr/core test -Ptests.profile=true
Alternatively, you can profile heap allocations instead:
-gradlew -p lucene/core test -Ptests.profile=true -Ptests.profile.mode=heap
+gradlew -p solr/core test -Ptests.profile=true -Ptests.profile.mode=heap
By default, results are computed (deduplicated) on just the method name,
folding
together all events from the same method. To drill down further, you can
increase the
stack size from the default of 1, to get a histogram of stacktraces instead:
-gradlew -p lucene/core test -Ptests.profile=true -Ptests.profile.stacksize=8
+gradlew -p solr/core test -Ptests.profile=true -Ptests.profile.stacksize=8
For big methods, it can also be helpful to include line numbers for more
granularity:
-gradlew -p lucene/core test -Ptests.profile=true
-Ptests.profile.linenumbers=true
+gradlew -p solr/core test -Ptests.profile=true -Ptests.profile.linenumbers=true
Using these additional options will make the results more sparse, so it may be
useful
to increase the top-N count:
-gradlew -p lucene/core test -Ptests.profile=true -Ptests.profile.count=100
+gradlew -p solr/core test -Ptests.profile=true -Ptests.profile.count=100
diff --git a/help/workflow.txt b/help/workflow.txt
index d70b243..eec7c4e 100644
--- a/help/workflow.txt
+++ b/help/workflow.txt
@@ -4,13 +4,13 @@ Typical workflow and tasks
This shows some typical workflow gradle commands.
Run tests on a module:
-gradlew -p lucene/core test
+gradlew -p solr/core test
Run test of a single-class (run "gradlew :helpTests" for more):
-gradlew -p lucene/core test --tests "*Demo*"
+gradlew -p solr/core test --tests "*Demo*"
Run all tests and validation checks on a module:
-gradlew -p lucene/core check
+gradlew -p solr/core check
Run all tests and validation checks on everything:
gradlew check
@@ -18,9 +18,9 @@ gradlew check
Run all validation checks but skip all tests:
gradlew check -x test
-Assemble a single module's JAR (here for lucene-core):
-gradlew -p lucene/core assemble
-ls lucene/core/build/libs
+Assemble a single module's JAR (here for solr-core):
+gradlew -p solr/core assemble
+ls solr/core/build/libs
Create all distributable packages, POMs, etc. and create a
local maven repository for inspection:
