Have something you'd like to contribute to the framework? 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 Statemachine 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!
Each Spring module is slightly different than another in terms of team size, number of issues, etc. Therefore each project is managed slightly different. You will notice that this document is very similar to the Spring Framework Contributor guidelines. However, there are some subtle differences between the two documents, so please be sure to read this document thoroughly.
The following provides information on setting up a development environment that can run the sample in Spring Tool Suite 3.6.0+. Other IDE's should work using Gradle's IDE support, but have not been tested.
Not sure what a pull request is, or how to submit one? Take a look at GitHub's excellent help documentation first.
Is there already an issue that addresses your concern? Do a bit of searching in our JIRA 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 not a user facing issue.
If you are considering anything more than correcting a typo or fixing a minor bug , please discuss it on the GitHub issues. We are happy to provide guidance but please spend an hour or two researching the subject on your own including searching the forums for prior discussions.
If you have not previously done so, please fill out and submit the SpringSource CLA form. You'll receive a token when this process is complete. Keep track of this, you may be asked for it later!
When 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.
You do not need to include your token/id. Please add the statement above to all future pull requests as well, simply so the Spring Statemachine team knows immediately that this process is complete.
Create your topic branch to be submitted as a pull request from master. The Spring team will consider your pull request for backporting on a case-by-case basis; you don't need to worry about submitting anything for backporting.
Branches used when submitting pull requests should preferably be named according to JIRA issues, e.g. 'SEC-1234'. Otherwise, use succinct, lower-case, dash (-) delimited names, such as 'fix-warnings', 'fix-typo', etc. This is important, because branch names show up in the merge commits that result from accepting pull requests, and should be as expressive and concise as possible.
#Keep commits focused
Remember each JIRA should be focused on a single item of interest since the JIRA tickets are used to produce the changelog. Since each commit should be tied to a JIRA, ensure that your commits are focused. For example, do not include an update to a transitive library in your commit unless the JIRA is to update the library. Reviewing your commits is essential before sending a pull request.
Please carefully follow the whitespace and formatting conventions already present in the framework.
Whitespace management tips
/* * Copyright 2002-2012 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 * * https://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 ...;
Always check the date range in the license header. For example, if you've modified a file in 2012 whose header still reads
* Copyright 2002-2011 the original author or authors.
then be sure to update it to 2012 appropriately
* Copyright 2002-2012 the original author or authors.
e.g.
/** * ... * * @author First Last * @since 3.2 * @see ... */
#Submit JUnit test cases for all behavior changes
Search the codebase to find related unit tests and add additional @Test
methods within.
FilterChainProxyTests
. An invalid name would be FilterChainProxyTest
.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: https://book.git-scm.com/4_interactive_rebasing.html.
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 <user@mail.com>
Rather, please include your first and last name, properly capitalized, as submitted against the SpringSource contributor license agreement:
Author: First Last <user@mail.com>
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-statemachine repository only by omitting the '--global' flag:
cd spring-statemachine git config user.name "First Last" git config user.email user@mail.com
SEC-1234: Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
cd spring-statemachine ./gradlew clean build
Subject line:
Follow the same conventions for pull request subject lines as mentioned above for commit message subject lines.
In the body:
Add a comment to the associated JIRA issue(s) linking to your new pull request.
The Spring team takes a very conservative approach to accepting contributions to the framework. This is to keep code quality and stability as high as possible, and to keep complexity at a minimum. Your changes, if accepted, may be heavily modified prior to merging. You will retain "Author:" attribution for your Git commits granted that the bulk of your changes remain intact. You may be asked to rework the submission for style (as explained above) and/or substance. Again, we strongly recommend discussing any serious submissions with the Spring Framework team prior to engaging in serious development work.
Note that you can always force push (git push -f) reworked / rebased commits against the branch used to submit your pull request. i.e. you do not need to issue a new pull request when asked to make changes.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。