Kay-Uwe Janssen edited this page Nov 24, 2016 · 13 revisions

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 do so, simply run this command in the AndroidAnnotations parent project: ./mvnw license:format
  • 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. You can adjust IntelliJ formatter settings and also add an editor inspection to check your coding style right in the IDE.

21/10/2018 The 4.5.2 release is out !

Using AndroidAnnotations


Enjoying AndroidAnnotations

Improving AndroidAnnotations

Extending AndroidAnnotations

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.