PaperMC/paper-api
Bukkit/Spigot 64ad50197f BREAKING: replace defunct PlayerChatEvent with async chat. Addresses BUKKIT-2064
PlayerChatEvent is now Deprecated. It should be fired asynchronously, but
has not been so traditionally. To do so would massively break plugins that
rely on it.

AsyncPlayerChatEvent now replaces PlayerChatEvent. It uses comparable
functionality, but can be fired without synchronizing to the event manager.
The event will sometimes fire synchronously if triggered by a plugin.

Because PlayerChatEvent is now deprecated, PlayerCommandPreprocessEvent will
no longer extend PlayerChatEvent. This is almost completely source and
binary compatible, bar plugins that downcast to PlayerChatEvent.
Additionally, some methods that are non-functional have been marked
deprecated and indicate such.

Additionally, new constructors are now provided to allow for lazier
initialization of the receiving player set. A note has been added stating
plugins should be prepared for UnsupportedOperationExceptions if the caller
provides an unmodifiable collection.

By: Wesley Wolfe <weswolf@aol.com>
2012-08-03 06:15:12 -05:00
..
src BREAKING: replace defunct PlayerChatEvent with async chat. Addresses BUKKIT-2064 2012-08-03 06:15:12 -05:00
.gitignore IntelliJ is awesome. 2011-07-05 00:14:31 -04:00
LICENCE.txt We're GPL. 2011-01-02 10:57:42 +01:00
pom.xml Update Bukkit for 1.3.1 changes 2012-07-29 02:34:09 -05:00
README.md Updated README.md with more coding and pull request conventions and tips to get your pull request accepted. 2012-02-24 00:08:31 -05:00

Bukkit

A Minecraft Server API.

Website: http://bukkit.org
Bugs/Suggestions: http://leaky.bukkit.org

Compilation

We use maven to handle our dependencies.

  • Install Maven 3
  • Check out this repo and: mvn clean install

Coding and Pull Request Conventions

  • We generally follow the Sun/Oracle coding standards.
  • No tabs; use 4 spaces instead.
  • No trailing whitespaces.
  • No CRLF line endings, LF only, put your gits 'core.autocrlf' on 'true'.
  • No 80 column limit or 'weird' midstatement newlines.
  • The number of commits in a pull request should be kept to a minimum (squish them into one most of the time - use common sense!).
  • No merges should be included in pull requests unless the pull request's purpose is a merge.
  • Pull requests should be tested (does it compile? AND does it work?) before submission.
  • Any major additions should have documentation ready and provided if applicable (this is usually the case).
  • Most pull requests should be accompanied by a corresponding Leaky ticket so we can associate commits with Leaky issues (this is primarily for changelog generation on dl.bukkit.org).
  • Try to follow test driven development where applicable.

Tips to get your pull request accepted

Making sure you follow the above conventions is important, but just the beginning. Follow these tips to better the chances of your pull request being accepted and pulled.

  • Make sure you follow all of our conventions to the letter.
  • Make sure your code compiles under Java 5.
  • Provide proper JavaDocs where appropriate.
  • Provide proper accompanying documentation where appropriate.
  • Test your code.
  • Make sure to follow coding best practises.
  • Provide a test plugin binary and source for us to test your code with.
  • Your pull request should link to accompanying pull requests.
  • The description of your pull request should provide detailed information on the pull along with justification of the changes where applicable.