diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..1a370a7 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,210 @@ +Contributor Guidelines +====================== + +Have something you'd like to contribute to **Spring Batch Extensions**? We welcome pull requests, but ask that you carefully read this document first to understand how best to submit them; what kind of changes are likely to be accepted; and what to expect from the Spring team when evaluating your submission. + +Please refer back to this document as a checklist before issuing any pull request; this will save time for everyone! + +## Understand the basics + +Not sure what a *pull request* is, or how to submit one? Take a look at GitHub's excellent [help documentation][] first. + +## Search the [GitHub Issue Tracker][] first; create an issue if necessary + +Is there already an issue that addresses your concern? Do a bit of searching in our [GitHub Issue Tracker][] to see if you can find something similar. If not, please create a new issue before submitting a pull request unless the change is truly trivial, e.g. typo fixes, removing compiler warnings, etc. + +## Sign the contributor license agreement + +Very important, before we can accept any *Spring Batch contributions*, we will need you to sign the contributor license agreement (CLA). Signing the CLA does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. In order to read and sign the CLA, please go to: + +* [https://support.springsource.com/spring_committer_signup](https://support.springsource.com/spring_committer_signup) + +For **Project**, please select **Spring Batch**. The **Project Lead** is **Michael Minella**. + +Once you've completed the web form, simply add the following in a comment on your pull request: + + I have signed and agree to the terms of the SpringSource Individual + Contributor License Agreement. + +## Fork the Repository + +1. Go to [https://github.com/spring-projects/spring-batch-extensions](https://github.com/spring-projects/spring-batch-extensions) +2. Hit the "fork" button and choose your own github account as the target +3. For more details see [http://help.github.com/fork-a-repo/](http://help.github.com/fork-a-repo/) + +## Setup your Local Development Environment + +1. `git clone git@github.com:/spring-batch-extensions.git` +2. `cd spring-batch-extensions` +3. `git remote show` +_you should see only 'origin' - which is the fork you created for your own github account_ +4. `git remote add upstream git@github.com:spring-projects/spring-batch-extensions.git` +5. `git remote show` +_you should now see 'upstream' in addition to 'origin' where 'upstream' is the *spring-projects*repository from which releases are built_ +6. `git fetch --all` +7. `git branch -a` +_you should see branches on origin as well as upstream, including 'master'_ + +## A Day in the Life of a Contributor + +* _Always_ work on topic branches (Typically an issue ID or descriptive identifier as the branch name). + - For example, to create and switch to a new branch for issue BATCHEXT-123: `git checkout -b BATCHEXT-123` +* You might be working on several different topic branches at any given time, but when at a stopping point for one of those branches, commit (a local operation). +* Please follow the "Commit Guidelines" described in this chapter of Pro Git: [http://progit.org/book/ch5-2.html](http://progit.org/book/ch5-2.html) +* Then to begin working on another issue (say BATCHEXT-101): `git checkout BATCHEXT-101`. The _-b_ flag is not needed if that branch already exists in your local repository. +* When ready to resolve an issue or to collaborate with others, you can push your branch to origin (your fork), e.g.: `git push origin BATCHEXT-123` +* If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and `git fetch ` to grab your branch. Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes. +* If you grant that collaborator push access to your repository, they can even apply their changes to your branch. +* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical *spring-batch-extensions* repository (what you know as 'upstream'), issue a pull request to the *spring-batch-extensions* repository (for more detail, see [http://help.github.com/send-pull-requests/](http://help.github.com/send-pull-requests/)). +* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it. +* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state. **This is the responsibility of any contributor.** If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make it merge-able. For a full explanation, see the Pro Git section on rebasing: [http://progit.org/book/ch3-6.html](http://progit.org/book/ch3-6.html). As stated there: "> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain." + +## Keeping your Local Code in Sync +* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want to always keep your own 'origin' master branch in synch with the 'upstream' master. +* Within your local working directory, you can sync up all remotes' branches with: `git fetch --all` +* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master and merging that into the branch you are in currently) +* Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b BATCHEXT-123` +* When you get to a stopping point: `git commit` +* If changes have occurred on the upstream/master while you were working you can synch again: + - Switch back to master: `git checkout master` + - Then: `git pull upstream master` + - Switch back to the topic branch: `git checkout BATCHEXT-123` (no -b needed since the branch already exists) + - Rebase the topic branch to minimize the distance between it and your recently synched master branch: `git rebase master` +(Again, for more detail see the Pro Git section on rebasing: [http://progit.org/book/ch3-6.html](http://progit.org/book/ch3-6.html)) +* **Note** You cannot rebase if you have already pushed your branch to your remote because you'd be rewriting history (see **'The Perils of Rebasing'** in the article). If you rebase by mistake, you can undo it as discussed [in this stackoverflow discussion](http://stackoverflow.com/questions/134882/undoing-a-git-rebase). Once you have published your branch, you need to merge in the master rather than rebasing. +* Now, if you issue a pull request, it is much more likely to be merged without conflicts. Most likely, any pull request that would produce conflicts will be deferred until the issuer of that pull request makes these adjustments. +* Assuming your pull request is merged into the 'upstream' master, you will actually end up pulling that change into your own master eventually, and at that time, you may decide to delete the topic branch from your local repository and your fork (origin) if you pushed it there. + - to delete the local branch: `git branch -d BATCHEXT-123` + - to delete the branch from your origin: `git push origin :BATCHEXT-123` + +## Maintain a linear commit history + +When issuing pull requests, please ensure that your commit history is linear. From the command line you can check this using: + +```` +git log --graph --pretty=oneline +```` + +As this may cause lots of typing, we recommend creating a global alias, e.g. `git logg` for this: + +```` +git config --global alias.logg 'log --graph --pretty=oneline' +```` + +This command, will provide the following output, which in this case shows a nice linear history: + +```` +* e412dd5bffeeed554c856f7453034aaa79b112a0 Fixed license reference to Spring Integration +* f728e867eed53489138391cf05fb6695c80592e3 Initial commit of the full README.md +* 6177cd39801967cc60c7701c5f553868b943f7ea Initial commit +```` + +If you see intersecting lines, that usually means that you forgot to rebase you branch. As mentioned earlier, **please rebase against master** before issuing a pull request. + +## Mind the whitespace + +Please carefully follow the whitespace and formatting conventions already present in the framework. + +1. Tabs, not spaces +2. Unix (LF), not DOS (CRLF) line endings +3. Eliminate all trailing whitespace +4. Wrap Javadoc at 90 characters +5. Aim to wrap code at 90 characters, but favor readability over wrapping +6. Preserve existing formatting; i.e. do not reformat code for its own sake +7. Search the codebase using `git grep` and other tools to discover common + naming conventions, etc. +8. Latin-1 (ISO-8859-1) encoding for Java sources; use `native2ascii` to convert + if necessary + +## Add Apache license header to all new classes + +```java +/* + * Copyright 2002-2014 the original author or authors. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package ...; +``` + +## Update license header to modified files as necessary + +Always check the date range in the Apache license header. For example, if you've modified a file in 2014 whose header still reads + +```java + * Copyright 2002-2011 the original author or authors. +``` + +then be sure to update it to 2014 appropriately + +```java + * Copyright 2002-2014 the original author or authors. +``` + +## Use @since tags + +Use @since tags for newly-added public API types and methods e.g. + +```java +/** + * ... + * + * @author First Last + * @since 3.0 + * @see ... + */ +``` + +## Submit JUnit test cases for all behavior changes + +Search the codebase to find related unit tests and add additional @Test methods within. It is also acceptable to submit test cases on a per issue basis. + +## Squash commits + +Use `git rebase --interactive`, `git add --patch` and other tools to "squash" multiple commits into atomic changes. In addition to the man pages for git, there are many resources online to help you understand how these tools work. Here is one: http://book.git-scm.com/4_interactive_rebasing.html. + +## Use your real name in git commits + +Please configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable: + + Author: Nickname + +Rather, please include your first and last name, properly capitalized, as submitted against the Spring contributor license agreement: + + Author: First Last + +This helps ensure traceability against the CLA, and also goes a long way to ensuring useful output from tools like `git shortlog` and others. + +You can configure this globally via the account admin area GitHub (useful for fork-and-edit cases); globally with + + git config --global user.name "First Last" + git config --global user.email user@mail.com + +or locally for the *spring-batch-extensions repository only by omitting the '--global' flag: + + cd spring-batch + git config user.name "First Last" + git config user.email user@mail.com + +## Run all tests prior to submission + +Make sure that all tests pass prior to submitting your pull request. + +## Mention your pull request on the associated issue + +Add a comment to the associated [GitHub Issue Tracker][] issue(s) linking to your new pull request. + +[help documentation]: http://help.github.com/send-pull-requests +[GitHub Issue Tracker]: https://github.com/spring-projects/spring-batch-extensions/issues + diff --git a/README.md b/README.md index d76327d..451b41e 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ Spring Batch Extensions ============================= -The Spring Batch Extensions project provides extension modules for [Spring Batch][]. This project is part of the [Spring organization][] on GitHub. +The Spring Batch Extensions project provides extension modules for the [Spring Batch Project][]. This project is part of the [Spring organization][] on GitHub. ## Available Modules @@ -25,13 +25,13 @@ on [Stack Overflow][]. [Commercial support][] is available too. ## Issue Tracking -Report issues via the [Spring Batch Extensions Issues][]. +Report issues via the Spring Batch Extensions [GitHub Issue Tracker][]. ## Building from source -Each module of the *Spring Batch Extensions* project is hosted as independent project with its own release cycle. For the build process of individual modules we recomend using a [Maven][]-based build system modelled after the [Spring Batch][] project. +Each module of the *Spring Batch Extensions* project is hosted as independent project with its own release cycle. For the build process of individual modules we recomend using a [Maven][] build system modelled after the [Spring Batch][] project. -Therefore, the following build instructions should generally apply for most, if not all, *Spring Batch Extensions*. In the instructions below, [`mvn`][] is invoked from the root of the source tree and serves as a cross-platform, self-contained bootstrap mechanism for the build. The only prerequisites are [Git][] and JDK 1.6+. +Therefore, the following build instructions should generally apply for most, if not all, *Spring Batch Extensions*. In the instructions below, `mvn` is invoked from the root of the source tree and serves as a cross-platform, self-contained bootstrap mechanism for the build. The only prerequisites are [Git][] and JDK 1.6+. ### Check out the sources @@ -39,11 +39,13 @@ Therefore, the following build instructions should generally apply for most, if ### Go into the directory of a specific module +`cd spring-batch-extensions` + `cd module-name` ### Compile and test, build all jars -`mvn package` +`mvn clean package` ### Install the modules jars into your local Maven cache @@ -53,13 +55,13 @@ Therefore, the following build instructions should generally apply for most, if ### Using Eclipse / STS -When using [SpringSource Tool Suite][] you can directly import Gradle based projects: +When using [Spring Tool Suite] you can directly import Maven based projects: `File -> Import -> Maven Project` Alternatively, you can also generate the Eclipse metadata (.classpath and .project files) using Maven: -`mvn eclipse` +`mvn eclipse:eclipse` Once complete, you may then import the projects into Eclipse as usual: @@ -69,11 +71,11 @@ Once complete, you may then import the projects into Eclipse as usual: To generate IDEA metadata (.iml and .ipr files), do the following: - mvn idea + mvn idea:idea ## Contributing -[Pull requests][] are welcome. Please see the [contributor guidelines][] for details. Additionally, if you are contributing, we recommend following the process for Spring Batch as outlined in the [administrator guidelines][]. +[Pull requests][] are welcome. Please see the [Contributor Guidelines][] for details. ## Staying in touch @@ -89,22 +91,19 @@ The Spring Batch Extensions Framework is released under version 2.0 of the [Apac **We look forward to your contributions!!** [Spring Batch]: https://github.com/spring-projects/spring-batch +[Spring Batch Project]: http://projects.spring.io/spring-batch/ [Spring organization]: https://github.com/spring-projects [spring-batch tag]: http://stackoverflow.com/questions/tagged/spring-batch [Stack Overflow]: http://stackoverflow.com/faq -[Commercial support]: asdf -[Spring Batch Extensions Issues]: https://github.com/mminella/spring-batch-extensions/issues -[the lifecycle of an issue]: https://github.com/cbeams/spring-framework/wiki/The-Lifecycle-of-an-Issue -[Gradle]: http://gradle.org -[`./gradlew`]: http://vimeo.com/34436402 +[Commercial support]: https://www.vmware.com/support/services/vfabric-developer.html +[GitHub Issue Tracker]: https://github.com/spring-projects/spring-batch-extensions/issues [Git]: http://help.github.com/set-up-git-redirect -[Gradle build and release FAQ]: https://github.com/SpringSource/spring-framework/wiki/Gradle-build-and-release-FAQ [Pull requests]: http://help.github.com/send-pull-requests -[contributor guidelines]: https://github.com/SpringSource/spring-integration/wiki/Contributor-guidelines -[administrator guidelines]: https://github.com/SpringSource/spring-integration/wiki/Administrator-Guidelines [Spring Batch Admin]: https://github.com/spring-projects/spring-batch-admin [Spring XD]: https://github.com/spring-projects/spring-xd [Spring for Apache Hadoop]: https://github.com/spring-projects/spring-hadoop [Spring Boot]: https://github.com/spring-projects/spring-boot [Spring Tool Suite]: http://spring.io/tools/sts [Apache License]: http://www.apache.org/licenses/LICENSE-2.0 +[Maven]: http://maven.apache.org +[Contributor Guidelines]: com/spring-projects/spring-batch-extensions/blob/master/CONTRIBUTING.md