Upstream/Paper
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2025-01-19 06:42:02 +01:00
Code Issues Projects Releases Wiki Activity
6e7076fd64
Paper/paper-api
History
Bukkit/Spigot 6e7076fd64 Moved all specific minecart entities to sub-package. 
This change is breaking for the new API for 1.5, including the interfaces for
the three new Minecart types and the name of the previously TNT_MINECART
material.

This change also deprecates the two previous specific minecart types located
in the org.bukkit.entity package. This deprecation is not a breaking change
and will still be internally supported.

Each minecart type has new javadoc to be slightly more descriptive. Included
with this are specific references to the interface for each respective
EntityType entry. Another package-info.java file has been included as well.

All specific minecart types extend minecart, each with a more descriptive
name. The naming will also follow the old convention. In addition, the
minecart with no specific designation is now more closely referred to as a
rideable minecart.

By: Wesley Wolfe <weswolf@aol.com>
2013-03-15 22:19:58 -05:00
..
src Moved all specific minecart entities to sub-package. 2013-03-15 22:19:58 -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 Minecraft 1.5 2013-03-13 17:32:25 -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

README.md

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.