Open Sourcing your Toast Module

Many teams choose to host their Toast Module on some kind of Open-Source platform at the end (or even during) build season. Because of this, I've written this short guide to what you should include in your README file so that people cloning your Repo can build your module.

Readme - Installation

Building and Setting up a Toast Module on a project that already exists is less steps than starting from scratch. Anyone cloning your repository or downloading your sources actually doesn't need Ruby or Hotplate. Instead, they can follow the steps below.

Include this in your README.md file:

To set up this module in your development environment, follow these steps:

1. Clone the repository

2. Run gradlew eclipse for Eclipse, or gradlew idea for IntelliJ (Linux/Mac users should use ./gradlew instead of gradlew.)
3. Edit the build.gradle file to reflect your desired configuration (e.g. changing the team number)

To build this module, simply run gradlew build. To deploy this module to your Robot, simply run gradlew deploy. If you haven't already, you can deploy Toast to your Robot by running gradlew toastDeploy.

To set up this module in your development environment, follow these steps:

1. Clone the repository  
2. Run `gradlew eclipse` for Eclipse, or `gradlew idea` for IntelliJ (Linux/Mac users should use `./gradlew` instead of `gradlew`.)  
3. Edit the `build.gradle` file to reflect your desired configuration (e.g. changing the team number)  

To build this module, simply run `gradlew build`.
To deploy this module to your Robot, simply run `gradlew deploy`.
If you haven't already, you can deploy [Toast](https://github.com/Open-RIO/ToastAPI) to your Robot by running `gradlew toastDeploy`.

Some friendly advice

Instead of getting people to build the module themselves, if you want to distribute the module, you can do so using Github's Releases system. The .jar file for your module is located under build/libs. This allows people to keep the module on a USB Device, as recommended by Toast.
It's recommended to change the getVersion() method inside of your Module class whenever you release a new version (trust me, this makes looking at error/crash reports so much simpler).

If you're stuck on choosing a license for your project, I'd recommend the MIT License. If you don't want to read the legal jargon, here's a tl;dr
DISCLAIMER: if for some reason you get involved in a legal dispute, don't take advice from me or this website. Read the license itself

PLEASE, PLEASE use a .gitignore file. I took the liberty of creating a template file that will ignore all the clutter in your repo (including temp, cache, workspace and run files). Get it here