This document provides a quick reference for common developer questions.
You create an empty file, similar to the /solr/licenses/antlr4-runtime-NOTICE.txt
Most committers already use a private fork branch for PRs. Use of central branches is ok for very collaborative work, but 95% of the time it is better to use a private branch to avoid extra mailing list traffic etc.
Periodically review https://github.com/apache/solr/branches/all to see if you have created a branch that can be deleted.
You can review instructions for running Solr in Docker in the Running in Docker developer doc.
Run gradle dev
, and then cd ./packaging/build/dev/
. Fire up your cluster
via bin/solr start -e cloud -noprompt
and then as you make changes to assets in /solr/webapp/web
,
run gradle dev
to redeploy the web assets. Do a hard refresh in your browser
to pick up your changes.
We use a number of tools for ensuring that Solr’s codebase follows our community standards. The most important tool is the very rich testing infrastructure that Solr enjoys. We strive for testing of every aspect of Solr. If you find a bug, write a test demonstrating it, so we can ensure that once the bug is squashed, it stays squashed.
Beyond testing, we also have some tools for ensuring coding standards are followed. Spotless is used to format the Java source code so that everyone uses the same formatting patterns. Run Spotless via:
./gradlew tidy
Learn more via ./gradlew :helpFormatting
.
The Eclipse IDE’s linting tool ECJ is applied as part of the check
task.
Error Prone goes beyond static type checking and recommends fixes for common bug patterns. Error Prone is run during the CI build on Jenkins, however to run it locally (and skip the tests) do:
./gradlew check -Pvalidation.errorprone=true -x test
In the same space as Errorprone is Sonatype Lift, an automated code reviewer that is run when you push your PR to Github. As with human reviewers, it’s a good practice to respond to each comment to reflect on the recommendation. Of course, automated code analysis will turn up false-positives. Tip: There is no point in responding to Lift with the ignore command because we don’t gate PRs on Lift.
There are Java classes and methods that Solr doesn’t allow.
This exclusion is enforced by the Forbidden APIs tool and is applied as part of the check
task.
Learn more about using Forbidden APIs via ./gradlew :helpForbiddenApis
.
To run a check for dependencies of Solr that have security vulnerabilities using the OWASP Gradle plugin. Run via:
./gradlew owasp
There are a number of other tasks that get run to validate the source code, and you can find them in the ./gradle/validation source tree.