Merge remote-tracking branch 'origin/main' into SOLR-17023

Resolved Conflicts:
	versions.lock
	versions.props

.asf.yaml

@@ -1,4 +1,4 @@
-# https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories
+# https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
 
 github:
   description: "Apache Solr open-source search software"
@@ -18,6 +18,26 @@ github:
     merge:  false
     rebase: false
 
+  # TODO: Add to this list for each new minor release
+  protected_branches:
+    main: {}
+    branch_9_0: {}
+    branch_9_1: {}
+    branch_9_2: {}
+    branch_9_3: {}
+    branch_9_4: {}
+    branch_9_5: {}
+    branch_9x: {}
+
+  protected_tags:
+    - "releases/*"
+
+  autolink_jira:
+    - SOLR
+
+  collaborators:
+    - solrbot
+
 notifications:
   commits:      [email protected]
   issues:       [email protected]

.github/labeler.yml

@@ -0,0 +1,172 @@
+# Add 'dependencies' label to any PR updating dependencies
+dependencies:
+  - changed-files:
+      - any-glob-to-any-file:
+        - versions.props
+        - versions.lock
+        - solr/licenses/**
+
+# Add 'documentation' label to any changes within ref-guide or dev-docs
+documentation:
+  - changed-files:
+      - any-glob-to-any-file:
+        - dev-docs/**
+        - solr/solr-ref-guide/**
+        - solr/documentation/**
+        - help/**
+        - solr/README.adoc
+        - CONTRIBUTING.md
+        - README.md
+
+# Add 'examples' label to examples
+examples:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/example/**
+
+# Add 'bats-tests' label
+bats-tests:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/packaging/tests/**
+
+# Add 'docker' label for changes to docker
+docker:
+  - changed-files:
+      - any-glob-to-any-file:
+        - solr/docker/**
+
+# Add 'tool:build' label for changes to gradle build files
+tool:build:
+  - changed-files:
+      - any-glob-to-any-file:
+          - '**/*.gradle'
+          - settings.gradle
+          - build.gradle
+          - gradle/**
+          - buildSrc/**
+
+# Add 'tools' label for changes to dev tools
+tool:scripts:
+  - changed-files:
+      - any-glob-to-any-file:
+          - dev-tools/**
+          - solr/server/scripts/cloud-scripts/**
+
+# Add jetty related labels
+jetty-server:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/server/etc/**
+          - solr/server/contexts/**
+          - solr/server/resources/**
+          - solr/server/modules/**
+
+# Add 'start-scripts' label for changes to start scripts
+start-scripts:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/bin/**
+
+# Add 'configs' label
+configs:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/server/solr/**
+
+# Add 'api' label
+api:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/api/**
+
+# Add 'client:solrj' labels
+client:solrj:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/solrj/**
+          - solr/solrj-*/**
+
+# Add 'test-framework' label
+test-framework:
+    - changed-files:
+        - any-glob-to-any-file:
+            - solr/test-framework/**
+
+# Add 'admin-ui' label
+admin-ui:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/webapp/**
+
+# Add 'prometheus-exporter' label
+prometheus-exporter:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/prometheus-exporter/**
+
+# Add labels for changes to solr modules
+module:analysis-extras:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/analytics-extras/**
+
+module:clustering:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/clustering/**
+
+module:extraction:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/extraction/**
+
+module:gcs-repository:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/gcs-repository/**
+
+module:hadoop-auth:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/hadoop-auth/**
+
+module:hdfs:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/hdfs/**
+
+module:jwt-auth:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/jwt-auth/**
+
+module:langid:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/langid/**
+
+module:ltr:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/ltr/**
+
+module:opentelemetry:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/opentelemetry/**
+
+module:s3-repository:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/s3-repository/**
+
+module:scripting:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/scripting/**
+
+module:sql:
+  - changed-files:
+      - any-glob-to-any-file:
+          - solr/modules/sql/**

.github/workflows/labeler.yml

@@ -0,0 +1,15 @@
+name: "Pull Request Labeler"
+on:
+  - pull_request_target
+
+jobs:
+  labeler:
+    permissions:
+      contents: read
+      pull-requests: write
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/labeler@v5
+        with:
+          sync-labels: true
+

.github/workflows/stale.yml

@@ -0,0 +1,38 @@
+# This workflow warns of PRs that have had no activity for a specified amount of time.
+#
+# For more information, see https://github.com/actions/stale
+name: Mark stale pull requests
+
+on:
+  # Run every day at 00:00 UTC
+  schedule:
+    - cron: '0 0 * * *'
+  # Or run on demand
+  workflow_dispatch:
+
+jobs:
+  stale:
+
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
+
+    steps:
+      - uses: actions/stale@v9
+        with:
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+
+          days-before-pr-stale: 60
+          days-before-issue-stale: -1   # we don't use issues
+          days-before-close: -1         # don't close stale PRs/issues
+          exempt-draft-pr: true         # don't mark draft PRs as stale
+          stale-pr-label: "stale"       # label to use when marking as stale
+
+          stale-pr-message: >
+            This PR had no visible activity in the past 60 days, labeling it as stale.
+            Any new activity will remove the stale label. To attract more reviewers, please tag
+            someone or notify the [email protected] mailing list.
+            Thank you for your contribution!
+
+          # TODO: Increase budget after initial testing
+          operations-per-run: 10        # operations budget

.github/workflows/tests-via-crave.yml

@@ -19,11 +19,11 @@ jobs:
       run: crave clone create --projectID 39 /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}
     - name: Checkout the correct branch
       run: |
-        git -C /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr fetch origin ${GITHUB_REF}:${GITHUB_REF}
-        git -C /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr checkout ${GITHUB_REF}
+        git -C /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER} fetch origin ${GITHUB_REF}:${GITHUB_REF}
+        git -C /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER} checkout ${GITHUB_REF}
     - name: Initialize, build, test
       run: |
-        cd /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
+        cd /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}
         crave run --clean
     - name: Delete Clone
       run: crave clone destroy -y /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}

NOTICE.txt

@@ -1,6 +1,6 @@
 ==============================================================
  Apache Solr
- Copyright 2006-2023 The Apache Software Foundation
+ Copyright 2006-2024 The Apache Software Foundation
 ==============================================================
 
 This product includes software developed at

dev-docs/FAQ.adoc

@@ -91,3 +91,10 @@ If you don't yet have an account, you have to ask for one in the 'users' or 'dev
 1. Please do not delete older files that you have already added - the complete history of an issue is important.
 1. The "Activity" section of an issue by default only lists "Comments". If you click on the "All" sub-tab you can see all activity related to this issue, including any edits that might have been made to the summary or description, as well as an commits that mention this issue in the commit log.
 1. Have follow up work to an existing issue that is closed?  If an issue is closed, its supposed to remain closed since it has been "shipped" in a release. Create a new issue and link it.
+
+=== Where can I find information about test history?
+
+* http://fucit.org/solr-jenkins-reports/failure-report.html
+* https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr*
+* https://lists.apache.org[Solr mailing list archives especially builds]
+

dev-docs/apis.adoc

@@ -51,27 +51,28 @@ Separating the API "definition" and "implementation" in this way allows us to on
 
 Writing a new v2 API may appear daunting, but additions in reality are actually pretty simple:
 
-1. *Create POJO ("Plain Old Java Object") classes as needed to represent the API's request and response*:
+. *Agree on Endpoint Syntax*: Before implementing, developers should generate consensus around what the new API will look like.  General guidelines and conventions for the v2 API syntax are described <<v2-api-conventions.adoc,here>>.
+. *Create POJO ("Plain Old Java Object") classes as needed to represent the API's request and response*:
 ** POJOs are used to represent both the body of the API request (for some `POST` and `PUT` endpoints), as well as the response from the API.
 ** Re-use of existing classes here is preferred where possible.  A library of available POJOs can be found in the `org.apache.solr.client.api.model` package of the `api` gradle project.
 ** POJO class fields are typically "public" and annotated with the Jackson `@JsonProperty` annotations to allow serialization/deserialization.
 ** POJO class fields should also have a Swagger `@Schema` annotation where possible, describing the purpose of the field.  These descriptions are technically non-functional, but add lots of value to our OpenAPI spec and any artifacts generated downstream.
-2. *Find or create an interface to hold the v2 API definition*:
+. *Find or create an interface to hold the v2 API definition*:
 ** API interfaces live in the `org.apache.solr.client.api.endpoint` package of the `api` gradle project.  Interfaces are usually given an "-Api" suffix to indicate their role.
 ** If a new API is similar enough to existing APIs, it may make sense to add the new API definition into an existing interface instead of creating a wholly new one.  Use your best judgement.
-3. *Add a method to the chosen interface representing the API*:
+. *Add a method to the chosen interface representing the API*:
 ** The method should take an argument representing each path and query parameter (annotated with `@PathParam` or `@QueryParam` as appropriate).  If the API is a `PUT` or `POST` that expects a request body, the method should take the request body POJO as its final argument, annotated with `@RequestBody`.
 ** Each method parameter should also be annotated with the Swagger `@Parameter` annotation.  Like the `@Schema` annotation mentioned above, `@Parameter` isn't strictly required for correct operation, but they add lots of value to our OpenAPI spec and generated artifacts.
 ** As a return value, the method should return the response-body POJO.
-4. *Futher JAX-RS Annotation*: The interface method in step (3) has specified its inputs and outputs, but several additional annotations are needed to define how users access the API, and to make it play nice with the code-generation done by Solr's build.
+. *Futher JAX-RS Annotation*: The interface method in step (3) has specified its inputs and outputs, but several additional annotations are needed to define how users access the API, and to make it play nice with the code-generation done by Solr's build.
 ** Each interface must have a `@Path` annotation describing the path that the API is accessed from.  Specific interface methods can also be given `@Path` annotations, making the "effective path" a concatenation of the interface and method-level values.  `@Path` supports a limited regex syntax, and curly-brackets can be used to create named placeholders for path-parameters.
 ** Each interface method should be given an HTTP-method annotation (e.g. `@GET`, `@POST`, etc.)
 ** Each interface method must be marked with a Swagger `@Operation` annotation.  This annotation is used to provide metadata about the API that appears in the OpenAPI specification and in any artifacts generated from that downstream.  At a minimum, `summary` and `tags` values should be specified on the annotation.  (`tags` is used by our SolrJ code generation to group similar APIs together.  Typically APIs are only given a single tag representing the plural name of the most relevant "resource" (e.g. `tags = {"aliases"}`, `tags = {"replica-properties"}`)
-5. *Create a class implementing the API interface*: Implementation classes live in the `core` gradle project, typically in the `org.apache.solr.handler` package or one of its descendants.
+. *Create a class implementing the API interface*: Implementation classes live in the `core` gradle project, typically in the `org.apache.solr.handler` package or one of its descendants.
 ** Implementing classes must extent `JerseyResource`, and are typically named similarly to the API interface created in (2) above without the "-Api" suffix. e.g. `class AddReplicaProperty extends JerseyResource implements AddReplicaPropertyApi`)
 ** Solr's use of Jersey offers us some limited dependency-injection ("DI") capabilities.  Class constructors annotated with `@Inject` can depend on a selection of types made available through DI, such as `CoreContainer`, `SolrQueryRequest`, `SolrCore`, etc.  See the factory-bindings in `JerseyApplications` (or other API classes) for a sense of which types are available for constructor injection.
 ** Add a body to your classes method(s).  For the most part this is "normal" Java development.
-6. *Register your API*: APIs must be registered to be available at runtime.  If the v2 API is associated with an existing v1 RequestHandler, the API class name can be added to the handler's `getJerseyResources` method.  If there is no associated RequestHandler, the API should be registered similar to other APIs in `CoreContainer.load`.
+. *Register your API*: APIs must be registered to be available at runtime.  If the v2 API is associated with an existing v1 RequestHandler, the API class name can be added to the handler's `getJerseyResources` method.  If there is no associated RequestHandler, the API should be registered similar to other APIs in `CoreContainer.load`.
 
 A good example for each of these steps can be seen in Solr's v2 "add-replica-property" API, which has a defining interface https://github.com/apache/solr/blob/9426902acb7081a2e9a1fa29699c5286459e1365/solr/api/src/java/org/apache/solr/client/api/endpoint/AddReplicaPropertyApi.java[AddReplicaPropertyApi], an implementing class https://github.com/apache/solr/blob/9426902acb7081a2e9a1fa29699c5286459e1365/solr/core/src/java/org/apache/solr/handler/admin/api/AddReplicaProperty.java[AddReplicaProperty], and the two POJOs https://github.com/apache/solr/blob/main/solr/api/src/java/org/apache/solr/client/api/model/AddReplicaPropertyRequestBody.java[AddReplicaPropertyRequestBody] and https://github.com/apache/solr/blob/main/solr/api/src/java/org/apache/solr/client/api/model/SolrJerseyResponse.java[SolrJerseyResponse].
 

dev-docs/dependency-upgrades.adoc

@@ -22,7 +22,7 @@ Keeping them up-to-date is crucial for a number of reasons:
 * minimizing the risk of critical CVE vulnerabilities by staying on a recent and supported version
 * avoiding "dependency hell", that can arise from falling too far behind
 
-Read the `help/dependencies.txt` file for an in-depth explanation of how gradle is deployed in Solr, using
+Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth explanation of how gradle is deployed in Solr, using
 https://github.com/palantir/gradle-consistent-versions[Gradle consistent-versions] plugin.
 
 == Manual dependency upgrades
@@ -56,4 +56,4 @@ choose to change to a less frequent schedule or disable the bot, by editing `ren
 === Configuring renovate.json
 While the bot runs on a https://github.com/solrbot/renovate-github-action[GitHub repo external to the project],
 the bot behavior can be tailored by editing `.github/renovate.json` in this project.
-See https://docs.renovatebot.com[Renovatebot docs] for available options.
+See https://docs.renovatebot.com[Renovatebot docs] for available options.

dev-docs/lucene-upgrade.md

@@ -80,3 +80,7 @@ gradlew test
 
 Push the local branch to github (fork) and open a pull request.
 
+## Looking for something else?
+
+Thanks for reading these upgrade steps! But perhaps you were looking for information on trying out prerelease Lucene changes or joint local Solr and Lucene development? If so then please see the 'Update Lucene prerelease' and 'Lucene local dependency substitution' sections in the [help/dependencies.txt](../help/dependencies.txt) documentation.
+