16 Contributing to Griffon - Reference Documentation
Authors: Andres Almiray
Version: 1.2.0
Table of Contents
16 Contributing to Griffon
Griffon is an open source project with an active community and we rely heavily on that community to help make Griffon better. As such, there are various ways in which people can contribute to Griffon. One of these is by writing useful plugins and making them publicly available. In this chapter, we'll look at some of the other options.16.1 Report Issues in JIRA
Griffon uses JIRA to track issues in the core framework, its documentation, its website, and many of the public plugins. If you've found a bug or wish to see a particular feature added, this is the place to start. You'll need to create a (free) JIRA account in order to either submit an issue or comment on an existing one.When submitting issues, please provide as much information as possible and in the case of bugs, make sure you explain which versions of Griffon and various plugins you are using. Also, an issue is much more likely to be dealt with if you attach a reproducible sample application.Reviewing issues
There are quite a few old issues in JIRA, some of which may no longer be valid. The core team can't track down these alone, so a very simple contribution that you can make is to verify one or two issues occasionally.Which issues need verification? A shared JIRA filter will display all issues that haven't been resolved. Just pick one or two of them and check whether they are still relevant.Once you've verified an issue, simply edit it by adding a "Last Reviewed" comment. If you think the issue can be closed, then also add a "Flagged" comment and a short explanation why.16.2 Build From Source and Run Tests
If you're interested in contributing fixes and features to the core framework, you will have to learn how to get hold of the project's source, build it and test it with your own applications. Before you start, make sure you have:- A JDK (1.6 or above)
- A git client
git clone http://github.com/griffon/griffon.git
Creating a Griffon installation
If you look at the project structure, you'll see that it doesn't look much like a standardGRIFFON_HOME
installation. But, it's very simple to turn it into one. Just run this from the root directory of the project:./gradlew installBinary
GRIFFON_HOME
pointing to a directory where the binaries will be placed. Once the above command has finished. When you next type run the griffon
command, you'll be using the version you just built.This will fetch all the standard dependencies required by Griffon and then build a GRIFFON_HOME
installation. Note that this target skips the extensive collection of Griffon test classes, which can take some time to complete.Running the test suite
All you have to do to run the full suite of tests is:./gradlew test
MappingDslTests
simply execute the following command:
./gradlew -Dtest.single=EnvironmentTests :griffon-rt:test
Developing in IntelliJ IDEA
You need to run the following gradle task:./gradlew idea
16.3 Submit Patches to Griffon Core
If you want to submit patches to the project, you simply need to fork the repository on GitHub rather than clone it directly. Then you will commit your changes to your fork and send a pull request for a core team member to review.Forking and Pull Requests
One of the benefits of GitHub is the way that you can easily contribute to a project by forking the repository and sending pull requests with your changes.What follows are some guidelines to help ensure that your pull requests are speedily dealt with and provide the information we need. They will also make your life easier!Create a local branch for your changes
Your life will be greatly simplified if you create a local branch to make your changes on. For example, as soon as you fork a repository and clone the fork locally, executegit checkout -b mine
Create JIRAs for non-trivial changes
For any non-trivial changes, raise a JIRA issue if one doesn't already exist. That helps us keep track of what changes go into each new version of Griffon.Include JIRA issue ID in commit messages
This may not seem particularly important, but having a JIRA issue ID in a commit message means that we can find out at a later date why a change was made. Include the ID in any and all commits that relate to that issue. If a commit isn't related to an issue, then there's no need to include an issue ID.Make sure your fork is up to date
Since the core developers must merge your commits into the main repository, it makes life much easier if your fork on GitHub is up to date before you send a pull request.Let's say you have the main repository set up as a remote called "upstream" and you want to submit a pull request. Also, all your changes are currently on the local "mine" branch but not on "master". The first step involves pulling any changes from the main repository that have been added since you last fetched and merged:git checkout master git pull upstream
git checkout mine git rebase master
git checkout master git merge mine
git push