22 Contributing to Grails 5.1.1

(Quick Reference) # 22 Contributing to Grails Version: 5.1.1 ## Table of Contents # 22 Contributing to Grails Grails is an open source project with an active community and we rely heavily on that community to help make Grails better. As such, there are various ways in which people can contribute to Grails. 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. ## 22.1 Report Issues in Github's issue tracker Grails uses Github to track issues in the core framework. Similarly for its documentation there is a separate tracker. If you’ve found a bug or wish to see a particular feature added, these are the places to start. You’ll need to create a (free) github account in order to either submit an issue or comment on an existing one in either of these. When submitting issues, please provide as much information as possible and in the case of bugs, make sure you explain which versions of Groovy, Grails and various plugins you are using. Other environment details - OS version, JDK, Gradle etc. should also be included. Also, an issue is much more likely to be dealt with if you upload a reproducible sample application on a github repository and provide a link in the issue. ### Reviewing issues There are quite a few old issues in github, 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? Going to the issue tracker will display all issues that haven’t been resolved. Once you’ve verified an issue, simply add a short comment explaining what you found. Be sure to metion your environment details and grails version. ## 22.2 Build From Source and Run Tests If you’re interested in contributing fixes and features to any part of grails, 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 (7 or above) A git client Once you have all the pre-requisite packages installed, the next step is to download the Grails source code, which is hosted at GitHub in several repositories owned by the "grails" GitHub user. This is a simple case of cloning the repository you’re interested in. For example, to get the core framework run:
    git clone http://github.com/grails/grails-core.git
This will create a "grails-core" directory in your current working directory containing all the project source files. The next step is to get a Grails installation from the source. ### Creating a Grails installation If you look at the project structure, you’ll see that it doesn’t look much like a standard `GRAILS_HOME` installation. But, it’s very simple to turn it into one. Just run this from the root directory of the project:
    ./gradlew install
This will fetch all the standard dependencies required by Grails and then build a `GRAILS_HOME` installation. Note that this target skips the extensive collection of Grails test classes, which can take some time to complete. Once the above command has finished, simply set the `GRAILS_HOME` environment variable to the checkout directory and add the "bin" directory to your path. When you next type `grails` command to run, you’ll be using the version you just built. If you are using SDKMAN then that can also be used to work with this local installation via the following:
    sdk install grails dev /path/to/grails-core
You will also need to publish your local installation to your local maven.
    ./gradlew pTML
Now you will have a dev version in your local which you can use to test your features. ### Running the test suite All you have to do to run the full suite of tests is:
    ./gradlew test
These will take a while (15-30 mins), so consider running individual tests using the command line. For example, to run the test spec `BinaryPluginSpec` simply execute the following command:
    ./gradlew :grails-core:test --tests *.BinaryPluginSpec
Note that you need to specify the sub-project that the test case resides in, because the top-level "test" target won’t work…​. ### Developing in IntelliJ IDEA You need to run the following gradle task:
    ./gradlew idea
Then open the project file which is generated in IDEA. Simple! ### Developing in STS / Eclipse You need to run the following gradle task:
    ./gradlew cleanEclipse eclipse
Before importing projects to STS do the following action: Edit grails-scripts/.classpath and remove the line "<classpathentry kind="src" path="../scripts"/>". Use "Import→General→Existing Projects into Workspace" to import all projects to STS. There will be a few build errors. To fix them do the following: Add the springloaded-core JAR file in $GRAILS_HOME/lib/org.springsource.springloaded/springloaded-core/jars to grails-core’s classpath. Remove "src/test/groovy" from grails-plugin-testing’s source path GRECLIPSE-1067 Add the jsp-api JAR file in $GRAILS_HOME/lib/javax.servlet.jsp/jsp-api/jars to the classpath of grails-web Fix the source path of grails-scripts. Add linked source folder linking to "../scripts". If you get build errors in grails-scripts, do "../gradlew cleanEclipse eclipse" in that directory and edit the .classpath file again (remove the line "<classpathentry kind="src" path="../scripts"/>"). Remove possible empty "scripts" directory under grails-scripts if you are not able to add the linked folder. Do a clean build for the whole workspace. To use Eclipse GIT scm team provider: Select all projects (except "Servers") in the navigation and right click → Team → Share project (not "Share projects"). Choose "Git". Then check "Use or create repository in parent folder of project" and click "Finish". Get the recommended code style settings from the mailing list thread (final style not decided yet, currently profile.xml). Import the code style xml file to STS in Window→Preferences→Java→Code Style→Formatter→Import . Grails code uses spaces instead of tabs for indenting. ### Debugging Grails or a Grails application To enable debugging, run:
    grails run-app --debug-jvm
By default Grails forks a JVM to run the application in. The `-debug-jvm` argument causes the debugger to be associated with the forked JVM. In order to instead attach the debugger to the build system which is going to fork the JVM use the `-debug` option:
    grails -debug run-app
## 22.3 Submit Patches to Grails 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! #### Make sure your fork is up to date Making changes to outdated sources is not a good idea. Someone else may have already made the change.
    git pull upstream master
#### 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, execute
    git checkout -b issue_123
This will create a new local branch called "issue_123" based off the "master" branch. Of course, you can name the branch whatever you like, but a good idea would be to reference the GitHub issue number that the change is relevant to. Each Pull Request should have its own branch. #### Create Github issues for non-trivial changes For any non-trivial changes, raise an issue on github if one doesn’t already exist. That helps us keep track of what changes go into each new version of Grails. #### Include github issue ID in commit messages This may not seem particularly important, but having a github 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 again and rebase 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 "issue_123" 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 master
This should complete without any problems or conflicts. Next, rebase your local branch against the now up-to-date master:
    git checkout issue_123
    git rebase master
What this does is rearrange the commits such that all of your changes come after the most recent one in master. Think adding some cards to the top of a deck rather than shuffling them into the pack. #### Push your branch to GitHub and send Pull Request Finally, you must push your changes to your fork on GitHub, otherwise the core developers won’t be able to pick them up:
    git push origin issue_123
| You should not merge your branch to your forks master. If the Pull Request is not accepted, your master will then be out of sync with upstream forever.
You’re now ready to send the pull request from the GitHub user interface. #### Say what your pull request is for A pull request can contain any number of commits and it may be related to any number of issues. In the pull request message, please specify the IDs of all issues that the request relates to. Also give a brief description of the work you have done, such as: "I refactored the data binder and added support for custom number editors. Fixes #xxxx". ## 22.4 Submit Patches to Grails Documentation ### Contributing Simple Changes The user guide is written using Asciidoctor. The simplest way to contribute fixes is to simply click on the "Improve this doc" link that is to the right of each section of the documentation. This will link to the Github edit screen where you can make changes, preview them and create a pull request. ### Building the Guide If you want to make significant changes, such as changing the structure of the table of contents etc. then we recommend you build the user guide. To do that simply checkout the sources from github:
    $ git clone https://github.com/grails/grails-doc/
    $ cd grails-doc
The source files can be found in the `src/en/guide` directory. Whilst the Table of Contents (TOC) is defined in the `src/en/guide/toc.yml` file. Each YAML key points to a Asciidoc template. For example consider the following YAML:
    introduction:
      title: Introduction
      whatsNew:
        title: What's new in Grails 3.2?
      ...
The `introduction` key points to `src/en/guide/introduction.adoc`. The `title` key defines the title that is dislayed in the TOC. Because `whatsNew` key is nested underneath the `introduction` key it points to `src/en/guide/introduction/whatsNew.adoc`, which is nested in a directory called `introduction`. Essentially, using the `toc.yml` file and the directory structure you can manipulate the structure of the user guide. To generate the documentation run the `publishGuide` task:
    $ ./gradlew publishGuide -x apiDocs
| In the above example we skip the `apiDocs` task to speed up building of the guide, otherwise all Groovydoc documentation will be built too!
Once the guide is built simply open the `build/docs/index.html` file in a browser to review your changes. | Quick Reference (hide)