HowToContributeCode

Contributing is not a crime

AndroidAnnotations greatly welcomes any contribution. Here is a small guide on how to contribute code, such as bug fixes, new features, javadoc or refactoring.

You should provide contributions by pushing changes on your fork of androidannotations, and letting us know by creating a pull request.

General Steps

• Fork the repository (you must be signed in Github)
• Create a local clone of your fork of AndroidAnnotations, create a branch based on the develop branch, commit some code on this branch, and push it on your own github repository.
• Your branch names must start with the issue number. The branch name should not contain the developer name, it should only contain the id of the issue and a meaningful name. For instance: 123_fragment_support.
• Do not include in your commit message anything related to automatic issue closing, such as Fixes issue 113. We'll do that when merging your pull request.
• Create a pull request, choose the right branch that should be integrated back in AndroidAnnotations.
• If you pull request is merged, update the wiki if needed with documentation about the new feature.

Checklist for contributed code

• All files should have an Apache 2 License header. To verify you added them, simply run this command in the AndroidAnnotations parent project: ./mvnw license:check
• Do not put any @author comment. Git keeps track of all your changes and @author does more harm then good.
• All annotations should have proper JavaDoc. Describe the feature, how it can be used and what limitation the annotation have and code examples. You can look at existing annotations for examples.
• Commits should be clear, traceable and grouped according to their intention as outlined in the this style guide. Commit messages should be clear and follow the standard git format.
• Always test features on as many IDEs and build environments as possible. The main reason is IDEs handle annotation-processing differently, Eclipse for example even uses it's own Java compiler.
• Every feature/fix should have at least a functional-test in the corresponding test module. Compile-time tests (under the processor module's src/test/java folder) should also be considered.
• Pay attention to indentation and notation. The coding style is enforced by Checkstyle in both command line build and CI.