You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by GitBox <gi...@apache.org> on 2022/09/22 17:33:26 UTC
[GitHub] [solr] epugh opened a new pull request, #1038: document the various code quality tools in our Developer FAQ
epugh opened a new pull request, #1038:
URL: https://github.com/apache/solr/pull/1038
https://issues.apache.org/jira/browse/SOLR-XXXXX
# Description
there has been some great work around code quality recently, and I realized that I don't really know what all the tools are that are available... So what is a new person going to do?
# Solution
Add an entry to the developer docs FAQ.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981151370
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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
Review Comment:
So, I guess we don't have a "we want 80 charaters more or less per line"? We don't have lint on that today... I'll make the change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
sonatype-lift[bot] commented on PR #1038:
URL: https://github.com/apache/solr/pull/1038#issuecomment-1259468426
:warning: **313 God Classes** were detected by Lift in this project. [Visit the Lift web console](https://lift.sonatype.com/results/github.com/apache/solr/01GDZDFJNAGAARSPQYKC2HMF0D?tab=technical-debt&utm_source=github.com&utm_campaign=lift-comment&utm_content=apache\%20solr) for more details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981426068
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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
Review Comment:
This isn't mandatory but is good-practice. Cassandra did lots of such changes over the ref guide, and I'm grateful for it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981427903
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
In your latest commit, you improved this to exclude tests so it's "good enough" but nonetheless, it'd be nice to show someone how to directly run this specific validation (as we do above for OWASP) rather than an entire build phase (`check`) and exclude various things.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981428994
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
I tried to find a actual "gradle target" (I think the word is) and didn't have any luck. I think it's welded directly into the check behavior...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981626145
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
So I am going to pretend to be @gerlowskija and say "Teperating this into it's own target is probably a seperate PR"...
So, do you think this is ready to commit?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r979062578
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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
Review Comment:
nit: when writing adoc files, consider one sentence per line. It helps with diffs.
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
that will also run tests; right? instead run the specific task if that's what we're trying to show someone.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh commented on PR #1038:
URL: https://github.com/apache/solr/pull/1038#issuecomment-1256109410
Do we think it's useful to add the RAT and other validations??? Or are we going beyond FAQ... I was on the fence about OWASP...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981486637
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
I turned up nothing as well; seems hooked into the compiler.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
risdenk commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r977924695
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,36 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
+
+There are Java classes and methods that Solr doesn't allow. This exclusion is enforced by the
+[Forbidden APIs](https://github.com/policeman-tools/forbidden-apis) tool and is applied as
+part of the `check` task. Learn more about using Forbidden APIs via `./gradlew :helpForbiddenApis`.
+
+We also check for security vulnerable components in Solr using the
+[OWASP](https://plugins.gradle.org/plugin/org.owasp.dependencycheck) Gradle plugin, as part of the
+`check` task.
Review Comment:
OWASP doesn't run by default. `./gradlew check -x test -Dvalidation.owasp=true` with the parameter is needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r978549344
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,36 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
+
+There are Java classes and methods that Solr doesn't allow. This exclusion is enforced by the
+[Forbidden APIs](https://github.com/policeman-tools/forbidden-apis) tool and is applied as
+part of the `check` task. Learn more about using Forbidden APIs via `./gradlew :helpForbiddenApis`.
+
+We also check for security vulnerable components in Solr using the
+[OWASP](https://plugins.gradle.org/plugin/org.owasp.dependencycheck) Gradle plugin, as part of the
+`check` task.
Review Comment:
reworked the text
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r981761662
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
Review Comment:
Absolutely; I approved 6 hours ago.
Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] janhoy commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
janhoy commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r978096690
##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,36 @@ 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](https://github.com/diffplug/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](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns. Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`
+
+There are Java classes and methods that Solr doesn't allow. This exclusion is enforced by the
+[Forbidden APIs](https://github.com/policeman-tools/forbidden-apis) tool and is applied as
+part of the `check` task. Learn more about using Forbidden APIs via `./gradlew :helpForbiddenApis`.
+
+We also check for security vulnerable components in Solr using the
+[OWASP](https://plugins.gradle.org/plugin/org.owasp.dependencycheck) Gradle plugin, as part of the
+`check` task.
Review Comment:
Can also be run independently with `./gradlew owasp`.
There was a plan to run OWASP checks in Jenkins, but I cannot find it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] epugh merged pull request #1038: document the various code quality tools in our Developer FAQ
Posted by GitBox <gi...@apache.org>.
epugh merged PR #1038:
URL: https://github.com/apache/solr/pull/1038
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org