AuthMeReloaded

Table of Contents

The issue tracker is used for managing bugs but also new features
Split issues if one becomes too complex
- One "work item" per issue guarantees a better overview
- If something is partially done in a milestone, open a follow-up issue so we can keep the milestone on the issue to reflect the truth
After implementation the issue is not closed but it is labeled as please verify, giving the reporter/someone else the chance to test

Three important groups of classes are: listeners, ExecutableCommand and services
- State is kept in services (not in commands or listener)
- Commands / listeners are the entry point for actions to be performed -> they typically forward work to the services after some input checks
- Arguments passed to ExecutableCommand always have the correct count! See Command Handling
BukkitService wraps calls to the Bukkit API so we can easily update / swap calls or implement different behavior centrally
We use dependency injection
- Injector acts a "singleton manager" and is responsible for setting members with the @Inject annotation

See Development Setup. In particular, note:
- Enable Maven skipLongHashTests profile locally
- You can enable Checkstyle checks in IntelliJ to be in sync with Code Climate
- How to have a runnable MC server with your local code

We use ConfigMe.
- Each property from config.yml lives in the code as a Property. See fr.xephi.authme.settings.properties
- A property's value can never be null
- Migration of settings with SettingsMigrationService
- Adding new settings is handled by ConfigMe - no migration necessarily

Tool tasks let us automatically update our docs and our plugin.yml
We have expiring structures (collections which let entries "expire" after a configured timeout)
Permission nodes are handled as enums extending PermissionNode (e.g. PlayerPermission)