Skip to content

Latest commit

 

History

History
69 lines (44 loc) · 3.2 KB

FAQ.adoc

File metadata and controls

69 lines (44 loc) · 3.2 KB

Frequently Asked Questions

FAQ

This document provides a quick reference for common developer questions.

What do I do with NOTICE.txt if I don’t have one to satisfy Gradle?

You create an empty file, similar to the /solr/licenses/antlr4-runtime-NOTICE.txt

What are best practices for branches in Git?

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.

How do I run Solr in Docker?

You can review instructions for running Solr in Docker in the Running in Docker developer doc.

Whats the fastest build lifecycle for frontend work on Solr Admin?

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.

How do we ensure coding standards and quality?

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.