Skip to content

Latest commit

 

History

History
executable file
·
58 lines (43 loc) · 3.58 KB

CONTRIBUTING.adoc

File metadata and controls

executable file
·
58 lines (43 loc) · 3.58 KB

Contributing to Reactive client for Apache Pulsar

Reactive client for Apache Pulsar is released under the Apache 2.0 license. If you would like to contribute something, or want to hack on the code this document should help you get started.

Using GitHub Issues

We use GitHub issues to track bugs and enhancements.

If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible. Ideally, that would include a small sample project that reproduces the problem.

Reporting Security Vulnerabilities

If you think you have found a security vulnerability in Apache Pulsar or Reactive client for Apache Pulsar please DO NOT disclose it publicly until we’ve had a chance to fix it. Please don’t report security vulnerabilities using GitHub issues, instead head over to https://github.com/apache/pulsar/security/policy and learn how to disclose them responsibly.

Code Conventions and Housekeeping

None of these is essential for a pull request, but they will all help. They can also be added after the original pull request but before a merge.

  • We use the Spring JavaFormat project to apply code formatting conventions. If you use Eclipse and you follow the ‘Importing into eclipse’ instructions below you should get project specific formatting automatically. You can also install the Spring JavaFormat IntelliJ Plugin or format the code from the Gradle build by running ./gradlew format.

  • The build includes Checkstyle rules for many of our code conventions. Run ./gradlew checkstyleMain checkstyleTest if you want to check your changes are compliant.

  • Make sure all new .java files have a Javadoc class comment, and preferably at least a paragraph on what the class is for.

  • Add the ASF license header comment to all new .java files (copy from existing files in the project).

  • Add some Javadocs.

  • A few unit tests would help a lot as well — someone has to do it.

  • Verification tasks, including tests and Checkstyle, can be executed by running ./gradlew check from the project root.

  • If no-one else is using your branch, please rebase it against the current main branch (or other target branch in the project).

  • When writing a commit message please follow these conventions.

Working with the Code

For information on editing, building, and testing the code, see the Working with the Code page on the project wiki.