Nuke more unused/ obsolete refs.

help/dependencies.txt

@@ -13,8 +13,8 @@ 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
-configurations and attach project dependencies to them:
+Lucene typically uses three configurations and attach project 
+dependencies to them:
 
 api  - makes a dependency available for main classes, tests and any
   other modules importing the project (exportable dependency),

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 Lucene's 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 Lucene tests. You can disable the parallelism
 entirely or assign it a 'low' priority with these properties:
 
 org.gradle.parallel=[true, false]

help/validateLogCalls.txt

@@ -1,74 +0,0 @@
-Using log calls
-===============
-
-There are several gotchas when logging. In particular, methods
-are called and strings are concatenated that have variables
-and objects can be constructed even if the logging level
-is more restrictive than the call. For instance, if the logging
-level is WARN, then a call like:
-log.trace("something {}", some_object.toString())
-will cause some_object.toString() to be called, then the resulting
-string is passed to log.trace() where the log level is evaluated
-and the logging call may be aborted. Any method called explicitly
-as part of a logging call is executed regardless of whether the
-message will be logged or not.
-
-This can be very expensive as per measurements with Java Flight
-Recorder. It's particularly egregious when complex operations
-are performed for, say, debug or trace levels, which
-are rarely reported.
-
-Here are a few patterns that generate useless strings/objects:
-
-- log.info("some stuff " + some_object) will concatenate the
-  some_object.toString() and create a new string. The only
-  exception is if "some_object" is a literal string.
-
-- log.info("some stuff {}", object.method()) will execute the
-  method.
-
-- log.info("some stuff {}", object.toString()) will execute
-  the toString and then may throw the results away.
-  log.info("some stuff{}", object)
-  is safe, the object's toString() method is called only after
-  the log/do not log decision has been made.
-
------------
-NOTES:
-
-- If you're creating a logging call that has no choice but to
-  do something expensive, surround it with "if (log.is*Enabled)".
-  Validation will flag any situation where the level in the "if"
-  clause does not match the level of the actual call.
-
-- Logging calls can take a bare exception, but do not
-  use the braces if you want the stack trace! So
-  log.info("stuff {}", exception) will not print the full stack,
-  log.info("stuff ", exception) _will_ print the full stack.
-  log.info("stuff {} ", some_object, exception) will print "stuff + the result
-  of the object's toString() method" plus the full stack. If you're puzzled
-  as to why so many logging calls don't have a matching number of curly-braces
-  and parameters, this is usually why.
-
-- When slf4j supports lambdas in logging calls (log4j2 does now),
-  we can use lambdas rather than "if log.is*Enabled". slf4j 2.0
-  will when released. This will probably mean this check has to be re-worked
-  to avoid false flags
-
-- warn, error, and fatal level messages are NOT flagged for explicit,
-  function calls, but will be flagged if they contain plusses that aren't
-  simple concatenation. This last is something of a style check.
-
-- You can get into some pretty convolued consructs trying to pass some of these
-  checks. Adding //nowarn, with or without spaces will cause the line to pass
-  no matter what. Please use this hack sparingly and be conscientious about
-  surrounding with 'if (log.is*Enabled)'.
-
-- String constants may be added with '+', but they _must_ be literal strings.
-  The compiler is smart enough to concatenate them when compiling. For example:
-  log.info("some {} "+ "more nonsense {}", object1, object2) is fine
-  log.info("some{} " + " more nonsense " + object1, object2) is NOT fine (note
-  the plus in front of object1).
-
-For a fuller discussion, see LUCENE-7788 and the other JIRAs linked
-from there.

help/workflow.txt

@@ -27,11 +27,6 @@ local maven repository for inspection:
 gradlew mavenLocal
 ls -R build/maven-local/
 
-Put together Solr distribution:
-gradlew -p solr/packaging assemble
-ls solr/packaging/build/distributions/solr-* # release archives
-ls solr/packaging/build/solr-*               # expanded directory
-
 
 Other validation and checks
 ===========================