Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

45 lines (31 sloc) 2.025 kB

Contributor Guidelines

Implementation-wise, the following things should be avoided as much as possible:

  • public mutable state
  • global state
  • implicit conversions
  • threadLocal
  • locks
  • casting
  • introducing new, heavy external dependencies

API design

  • Play is a Java and Scala framework, make sure your changes are working for both API-s
  • Java APIs should go to framework/play/src/main/java, package structure is play.myapipackage.xxxx
  • Scala APIs should go to framework/play/src/main/scala, where the package structure is play.api.myapipackage
  • Java and Scala APIs should be implemented the following way:
    • implement the core API in scala (play.api.xxx)
    • if your component requires life cycle management or needs to be swappable, create a plugin, otherwise skip this step
    • wrap core API for scala users (example)
    • wrap scala API for java users (example)
  • features are forever, always think about whether a new feature really belongs to the core framework or it should be implemented as a plugin
  • if you are in doubt, ask on the mailing list

Testing and documentation

  • each and every public facing method and class need to have a corresponding scaladoc or javadoc with examples, description etc.
  • each feature and bug fix requires either a functional test (framework/integrationtest) or a spec (/play/src/test)
  • run Play's integration test suite framework/runtests before pushing. If a test fails, fix it, do not ignore it.

source format

  • run scalariform-format before commit

git commits

  • prefer rebase
  • bigger changesets

lighthouse

Please always create a corresponding ticket in Lighthouse before sending a pull request

Jump to Line
Something went wrong with that request. Please try again.