What is Vanilla?

Vanilla is a plugin for the Spout platform that provides vanilla Minecraft functionality and gameplay.

Copyright (c) 2011-2012, VanillaDev <http://www.spout.org/>

Who is VanillaDev?

VanillaDev is the team behind the Vanilla and BukkitBridge projects.

Visit our website or get support on our forums.
Track and submit issues and bugs on our issue tracker.

Source

The latest and greatest source can be found on GitHub.
Download the latest builds from Jenkins.
View the latest Javadoc.

License

Vanilla is licensed under the GNU Lesser General Public License Version 3, but with a provision that files are released under the MIT license 180 days after they are published. Please see the LICENSE.txt file for details.

Compiling

Vanilla uses Maven to handle its dependencies.

• Install Maven 2 or 3
• Checkout this repo and run: mvn clean install

Using with Your Project

For those using Maven to manage project dependencies, simply include the following in your pom.xml:

<dependency>
    <groupId>org.spout</groupId>
    <artifactId>vanilla</artifactId>
    <version>1.2.5-SNAPSHOT</version>
</dependency>

If you do not already have repo.spout.org in your repository list, you will need to add this also:

<repository>
    <id>spout-repo</id>
    <url>https://repo.spout.org</url>
</repository>

Coding and Pull Request Formatting

• Generally follow the Oracle coding standards.
• Use tabs, no spaces.
• No trailing whitespaces.
• 200 column limit for readability.
• All new files must include the license header. This can be done automatically with Maven by running mvn clean.
• All changes made via pull requests first be compiled locally to verify that the code does indeed compile, and tested to verify that it actually works.
• Where practical, a test should be included to verify the change. Except in exceptional cases, bug fixes MUST include a test case which fails for the current version and passes for the updated version.
• Commit messages must include:
  • A brief description of the change
  • A more detailed description of the change (second line and below, optional)
  • Sign-off, verifying agreement with the license terms
• Number of commits in a pull request should be kept to one commit and all additional commits must be squashed except for circumstantial exceptions.
• You may have more than one commit in a pull request if the commits are separate changes, otherwise squash the commits.
• For clarification, see the full pull request guidelines here.

Please follow the above conventions if you want your pull request(s) accepted.