|
| 1 | +# Contributing to the Java Client API |
| 2 | + |
| 3 | +The Java Client API welcomes new contributors. This document will guide you |
| 4 | +through the process. |
| 5 | + |
| 6 | + - [Question or Problem?](#question) |
| 7 | + - [Issues and Bugs](#issue) |
| 8 | + - [Feature Requests](#feature) |
| 9 | + - [Submission Guidelines](#submit) |
| 10 | + |
| 11 | +## <a name="question"></a> Got a Question or Problem? |
| 12 | + |
| 13 | +If you have questions about how to use the Java Client API, you can ask on |
| 14 | +[StackOverflow](http://stackoverflow.com/tags/marklogic), tagging the question |
| 15 | +with MarkLogic. |
| 16 | + |
| 17 | +## <a name="issue"></a> Found an Issue? |
| 18 | +If you find a bug in the source code or a mistake in the documentation, you can help us by |
| 19 | +submitting an issue to our [GitHub Issue |
| 20 | +Tracker](https://github.com/marklogic/java-client-api/issues). Even better you |
| 21 | +can submit a Pull Request with a fix for the issue you filed. |
| 22 | + |
| 23 | +## <a name="feature"></a> Want a Feature? |
| 24 | +You can request a new feature by submitting an issue to our |
| 25 | +[GitHub Issue Tracker](https://github.com/marklogic/java-client-api/issues). |
| 26 | +If you would like to implement a new feature then first create a new issue and |
| 27 | +discuss it with one of our project maintainers. |
| 28 | + |
| 29 | +## <a name="submit"></a> Submission Guidelines |
| 30 | + |
| 31 | +### Submitting an Issue |
| 32 | +If your issue appears to be a bug, and hasn't been reported, open a new issue. |
| 33 | +Providing the following information will increase the chances of your issue |
| 34 | +being dealt with quickly: |
| 35 | + |
| 36 | +* **Overview of the Issue** - if an error is being thrown a stack trace helps |
| 37 | +* **Motivation for or Use Case** - explain why this is a bug for you |
| 38 | +* **Environment** - Mac, windows? Firefox, Chrome? details help |
| 39 | +* **Suggest a Fix** - if you can't fix the bug yourself, perhaps you can point |
| 40 | +to what might be causing the problem (line of code or commit) |
| 41 | + |
| 42 | +### Submitting a Pull Request |
| 43 | + |
| 44 | +#### Fill in the CLA |
| 45 | + |
| 46 | +Before we can accept your pull request, we need you to sign the [Contributor |
| 47 | +License Agreement](http://developer.marklogic.com/products/cla). |
| 48 | + |
| 49 | +#### Fork the Java Client API |
| 50 | + |
| 51 | +Fork the project [on GitHub](https://github.com/marklogic/java-client-api/fork) |
| 52 | +and clone your copy. |
| 53 | + |
| 54 | + $ git clone [email protected]:username/java-client-api.git |
| 55 | + $ cd java-client-api |
| 56 | + $ git remote add upstream git://github.com/marklogic/java-client-api.git |
| 57 | + |
| 58 | +All bug fixes and new features go into the |
| 59 | +[develop](https://github.com/marklogic/java-client-api/tree/develop) branch. |
| 60 | + |
| 61 | +We ask that you open an issue in the |
| 62 | +[issue tracker](https://github.com/marklogic/java-client-api/issues) |
| 63 | +and get agreement from at least one of the project maintainers before you start |
| 64 | +coding. |
| 65 | + |
| 66 | +Nothing is more frustrating than seeing your hard work go to waste because |
| 67 | +your vision does not align with that of a project maintainer. |
| 68 | + |
| 69 | +#### Choose the appropriate branch |
| 70 | + |
| 71 | +While the \*master branches reflect the latest released code for the |
| 72 | +corresponding server release, the \*develop branches reflect the latest changes |
| 73 | +that will be released next and are therefore the right place to commit changes. |
| 74 | +To be clear, the following branches have the assigned meaning: |
| 75 | +* develop - the place to make changes for the next release |
| 76 | +* master - the stable code from the last release |
| 77 | +* 3.0-develop - the place to make changes for the next 3.x release (corresponds with the next server 8.x release) |
| 78 | +* 3.0-master - the stable code from the last 3.x release (corresponds with the latest server 8.x release) |
| 79 | +* 2.0-develop - the place to make changes for the next 2.x release (corresponds with the next server 7.x release) |
| 80 | +* 2.0-master - the stable code from the last 2.x release (corresponds with the latest server 7.x release) |
| 81 | +* 1.0-develop - the place to make changes for the next 1.x release (corresponds with the next server 6.x release) |
| 82 | +* 1.0-master - the stable code from the last 1.x release (corresponds with the latest server 6.x release) |
| 83 | + |
| 84 | +#### Create a branch for your changes |
| 85 | + |
| 86 | +Okay, so you have decided to fix something. Create a feature branch |
| 87 | +and start hacking: |
| 88 | + |
| 89 | + $ git checkout -b my-feature-branch -t origin/develop |
| 90 | + |
| 91 | +#### Commit your changes |
| 92 | + |
| 93 | +Make sure git knows your name and email address: |
| 94 | + |
| 95 | + $ git config --global user.name "J. Random User" |
| 96 | + $ git config --global user.email "[email protected]" |
| 97 | + |
| 98 | +Writing good commit logs is important. A commit log should describe what |
| 99 | +changed and why. Follow these guidelines when writing one: |
| 100 | + |
| 101 | +1. The first line should be 50 characters or less and contain a short |
| 102 | + description of the change including the Issue number prefixed by a hash (#). |
| 103 | +2. Keep the second line blank. |
| 104 | +3. Wrap all other lines at 72 columns. |
| 105 | + |
| 106 | +A good commit log looks like this: |
| 107 | + |
| 108 | +``` |
| 109 | +Fixing Issue #123: make the whatchamajigger work in MarkLogic 8 |
| 110 | +
|
| 111 | +Body of commit message is a few lines of text, explaining things |
| 112 | +in more detail, possibly giving some background about the issue |
| 113 | +being fixed, etc etc. |
| 114 | +
|
| 115 | +The body of the commit message can be several paragraphs, and |
| 116 | +please do proper word-wrap and keep columns shorter than about |
| 117 | +72 characters or so. That way `git log` will show things |
| 118 | +nicely even when it is indented. |
| 119 | +``` |
| 120 | + |
| 121 | +The header line should be meaningful; it is what other people see when they |
| 122 | +run `git shortlog` or `git log --oneline`. |
| 123 | + |
| 124 | +#### Rebase your repo |
| 125 | + |
| 126 | +Use `git rebase` (not `git merge`) to sync your work from time to time. |
| 127 | + |
| 128 | + $ git fetch upstream |
| 129 | + $ git rebase upstream/develop |
| 130 | + |
| 131 | +#### Test your code |
| 132 | + |
| 133 | +Be sure to run the tests before submitting your pull request. PRs with failing |
| 134 | +tests won't be accepted. |
| 135 | + |
| 136 | +First verify that you have valid server and admin auth info in |
| 137 | +`SERVER_ADMIN_USER` and `SERVER_ADMIN_PASS` fields in |
| 138 | +src/test/java/com/marklogic/client/test/Common.java |
| 139 | + |
| 140 | + $ ./gradlew clean |
| 141 | + $ ./gradlew testServerInit |
| 142 | + $ ./gradlew test |
| 143 | + |
| 144 | + |
| 145 | +#### If your server is not on localhost |
| 146 | + |
| 147 | +You can either create SSH tunnels to your server on ports 8000, 8002, and 8012 |
| 148 | +by a command like: |
| 149 | + |
| 150 | + ssh -L 8000:localhost:8000 -L 8002:localhost:8002 -L 8012:localhost:8012 user@hostname |
| 151 | + |
| 152 | +Or you can update the static `HOST` field in |
| 153 | +src/test/java/com/marklogic/client/test/Common.java |
| 154 | +and the `example.host` property in src/main/resources/Example.properties. |
| 155 | + |
| 156 | +#### Push your changes |
| 157 | + |
| 158 | + $ git push origin my-feature-branch |
| 159 | + |
| 160 | +#### Submit the pull request |
| 161 | + |
| 162 | +Go to https://github.com/username/java-client-api and select your feature |
| 163 | +branch. Click the 'Pull Request' button and fill out the form. |
| 164 | + |
| 165 | +Pull requests are usually reviewed within a few days. If you get comments that |
| 166 | +need to be to addressed, apply your changes in a separate commit and push that |
| 167 | +to your feature branch. Post a comment in the pull request afterwards; GitHub |
| 168 | +does not send out notifications when you add commits to existing pull requests. |
| 169 | + |
| 170 | +That's it! Thank you for your contribution! |
| 171 | + |
| 172 | + |
| 173 | +#### After your pull request is merged |
| 174 | + |
| 175 | +After your pull request is merged, you can safely delete your branch and pull |
| 176 | +the changes from the main (upstream) repository: |
| 177 | + |
| 178 | +* Delete the remote branch on GitHub either through the GitHub web UI or your |
| 179 | +local shell as follows: |
| 180 | + |
| 181 | + $ git push origin --delete my-feature-branch |
| 182 | + |
| 183 | +* Check out the *develop* branch: |
| 184 | + |
| 185 | + $ git checkout develop -f |
| 186 | + |
| 187 | +* Delete the local branch: |
| 188 | + |
| 189 | + $ git branch -D my-feature-branch |
| 190 | + |
| 191 | +* Update your *develop* with the latest upstream version: |
| 192 | + |
| 193 | + $ git pull --ff upstream develop |
0 commit comments