Contributing

Developer's note

These are instructions for the 9.0.0+ version of the CommandAPI. CommandAPI 9.0.0 onwards has a completely different project structure!

Thanks for considering contributing to the CommandAPI! We're always happy to receive new improvements from developers to create a powerful and sustainable Minecraft API.

Useful resources:

• If you haven't joined the CommandAPI Discord, feel free to come find us! We can assure you that we don't bite.
• Found a bug or have a suggestion and aren't quite sure how to tackle it? Open a GitHub issue and we can work it out together.

Where should I start?

The CommandAPI makes up a number of subprojects:

• CommandAPI annotation API
• CommandAPI for various platforms
  • CommandAPI for Bukkit
    • CommandAPI Bukkit plugin
    • CommandAPI Bukkit testing matrix
  • CommandAPI for Velocity
  • CommandAPI for Sponge
• CommandAPI documentation and website
  • CommandAPI JavaDocs
  • CommandAPI documentation examples
  • CommandAPI published documentation
  • CommandAPI command visualizer
• CommandAPI examples

How do I submit changes?

To submit new changes, open a new pull request to the dev/dev branch with a list of what you've done - please do not open a pull request to the master branch!

Pull request checklist:

• Does the pull request have suitable commit messages that describes the changes in the commit?
• Does the CommandAPI compile successfully? (This will be checked automatically when a pull request is made)
• Has this been tested in a Minecraft server environment if necessary (e.g. the latest compatible version of Minecraft and using Spigot or Paper).
• Does this need unit tests, and if so, has unit tests been written for this pull request?
• Does this need documentation, and if so, has documentation been written for this pull request?

If the pull request is a new feature, some documentation for the feature should be provided in a new Markdown file in docssrc/src if the feature is relatively complex, requiring various steps to use the feature. If the feature is simple enough to explain with a few examples, please include these in your pull request description instead of creating a Markdown documentation file.

If the pull request is a cosmetic change (e.g. fixing whitespace or code formatting), since cosmetic changes don't add anything of value to the CommandAPI's functionality or stability, these will generally not be accepted.

Coding conventions

We don't have any overly strict conventions, but these are a must:

• Use tabs instead of spaces, except for documentation-facing example code (such as commandapi-core/src/main/test/Examples.java).
• Avoiding Java's Streams API, in favour of for loops or while loops for code that will run on a Minecraft server.
• Avoid the use of null wherever possible. If null must be used, consider using optionals.
• If using reflection or otherwise, all required fields must be declared at the top of the file with @RequireField.
• If you are adding a new developer-facing API method, suitable JavaDocs must be provided.

Additionally, the following are recommended but not overly enforced:

• In general, stick to the formatting of Java code in surrounding code blocks or contexts. By default, we use the built-in Eclipse IDE Java formatter, except for cases where this sacrifices readability of the code, such as builder function calls.
• Avoiding the use of reflection, in favour of VarHandles.
• If a field in a method will be used a lot and isn't going to be modified, make it final.