Skip to content

Commit

Permalink
refactor.
Browse files Browse the repository at this point in the history
  • Loading branch information
@damonxue
damonxue committed Sep 12, 2023
1 parent 2e0c9c3 commit 4d6b274
Show file tree
Hide file tree
Showing 176 changed files with 1,921 additions and 1,914 deletions.
8 changes: 4 additions & 4 deletions .asf.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,12 +25,12 @@ github:
issues: true
projects: true
enabled_merge_buttons:
squash: false
merge: true
rebase: false
squash: false
merge: true
rebase: false

notifications:
pullrequests: [email protected]
commits: [email protected]
issues: [email protected]
issues: [email protected]
jira_options: link label worklog
47 changes: 20 additions & 27 deletions .github/pull_request_template.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,36 +5,29 @@ For more details on how to report a vulnerablity see: https://www.apache.org/sec

Following this checklist to help us incorporate your contribution quickly and easily:

- [ ] Make sure there is a [GitHub issue](https://github.com/apache/shiro/issues) filed
for the change (usually before you start working on it). Trivial changes like typos do not
require a GitHub issue. Your pull request should address just this issue, without pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line and body.
- [ ] Format the pull request title like `[#XXX] - Fixes bug in SessionManager`,
where you replace `#XXX` with the appropriate GitHub issue. Best practice
is to use the GitHub issue title in the pull request title and in the first line of the commit message.
- [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [ ] add `fixes #XXX` if merging the PR should close a related issue.
- [ ] Run `mvn verify` to make sure basic checks pass. A more thorough check will be performed on your pull request
automatically.
- [ ] If you have a group of commits related to the same change, please squash your commits into one and force push your
branch using `git rebase -i`.
- [ ] Committers: Make sure a milestone is set on the PR

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
- [ ] Make sure there is a [GitHub issue](https://github.com/apache/shiro/issues) filed
for the change (usually before you start working on it). Trivial changes like typos do not
require a GitHub issue. Your pull request should address just this issue, without pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line and body.
- [ ] Format the pull request title like `[#XXX] - Fixes bug in SessionManager`,
where you replace `#XXX` with the appropriate GitHub issue. Best practice
is to use the GitHub issue title in the pull request title and in the first line of the commit message.
- [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [ ] add `fixes #XXX` if merging the PR should close a related issue.
- [ ] Run `mvn verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
- [ ] If you have a group of commits related to the same change, please squash your commits into one and force push your branch using `git rebase -i`.
- [ ] Committers: Make sure a milestone is set on the PR

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
In this case, just format the pull request title like `[DOC] - Add javadoc in SessionManager`.

If this is your first contribution, you have to read the [Contribution Guidelines](https://github.com/apache/shiro/blob/master/CONTRIBUTING.md)

If this is your first contribution, you have to read
the [Contribution Guidelines](https://github.com/apache/shiro/blob/master/CONTRIBUTING.md)

If your pull request is about ~20 lines of code you don't need to sign
an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)
If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)
if you are unsure please ask on the developers list.

To make clear that you license your contribution under
the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.

- [ ] I hereby declare this contribution to be licenced under
the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file
an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
- [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
53 changes: 18 additions & 35 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,7 @@ Contributing to Apache Shiro

Summary
-------
This document covers how to contribute to the Apache Shiro project. These instructions assume you have a GitHub.com
account, so if you don't have one you will have to create one. Your proposed code changes will be published to your own
fork of the Apache Shiro project and you will submit a Pull Request for your changes to be added.
This document covers how to contribute to the Apache Shiro project. These instructions assume you have a GitHub.com account, so if you don't have one you will have to create one. Your proposed code changes will be published to your own fork of the Apache Shiro project and you will submit a Pull Request for your changes to be added.

_Lets get started!!!_

Expand All @@ -17,8 +15,7 @@ In your browser, navigate to: [https://github.com/apache/shiro](https://github.c

Fork the repository by clicking on the 'Fork' button on the top right hand side.
The fork will happen and you will be taken to your own fork of the repository.
Copy the Git repository URL by clicking on the clipboard next to the URL on the right hand side of the page under '*
*HTTPS** clone URL'.
Copy the Git repository URL by clicking on the clipboard next to the URL on the right hand side of the page under '**HTTPS** clone URL'.
You will paste this URL when doing the following `git clone` command.

On your computer, follow these steps to setup a local repository for working on Apache Shiro:
Expand All @@ -32,18 +29,15 @@ $ git fetch upstream
$ git rebase upstream/main
```


Making changes
--------------

It is important that you create a new branch to make changes on and that you do not change the `main` branch (other than
to rebase in changes from `upstream/main`).
In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch
will be created on your local repository and
will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for
the changes to be added to the Apache Shiro project.
It is important that you create a new branch to make changes on and that you do not change the `main` branch (other than to rebase in changes from `upstream/main`).
In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and
will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the Apache Shiro project.

It is best practice to create a new branch each time you want to contribute to the project and only track the changes
for that pull request in this branch.
It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch.

``` bash
$ git checkout -b feature_x
Expand All @@ -53,20 +47,16 @@ $ git add .
$ git commit -a -m "descriptive commit message for your changes"
```

> The `-b` specifies that you want to create a new branch called `feature_x`. You only specify `-b` the first time you
> checkout because you are creating a new branch.
> The `-b` specifies that you want to create a new branch called `feature_x`. You only specify `-b` the first time you checkout because you are creating a new branch.
> Once the `feature_x` branch exists, you can later switch to it with only `git checkout feature_x`.

Rebase `feature_x` to include updates from `upstream/main`
------------------------------------------------------------

It is important that you maintain an up-to-date `main` branch in your local repository. This is done by rebasing in the
code changes from `upstream/main`
(the official Apache Shiro project repository) into your local repository. You will want to do this before you start
working on a feature as well as right
before you submit your changes as a pull request. I recommend you do this process periodically while you work to make
sure you are working off the most recent project code.
It is important that you maintain an up-to-date `main` branch in your local repository. This is done by rebasing in the code changes from `upstream/main`
(the official Apache Shiro project repository) into your local repository. You will want to do this before you start working on a feature as well as right
before you submit your changes as a pull request. I recommend you do this process periodically while you work to make sure you are working off the most recent project code.

This process will do the following:

Expand All @@ -88,12 +78,10 @@ $ git rebase main
Make a GitHub Pull Request to contribute your changes
-----------------------------------------------------

When you are happy with your changes and you are ready to contribute them, you will create a Pull Request on GitHub to
do so. This is done by pushing your local changes
When you are happy with your changes and you are ready to contribute them, you will create a Pull Request on GitHub to do so. This is done by pushing your local changes
to your forked repository (default remote name is `origin`) and then initiating a pull request on GitHub.

> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/main`
_before_ you do this.
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/main` _before_ you do this.
``` bash
$ git push origin main
Expand All @@ -104,27 +92,22 @@ Now that the `feature_x` branch has been pushed to your GitHub repository, you c

To initiate the pull request, do the following:

1. In your browser, navigate to your forked
repository: [https://github.com/YOUR_ACCOUNT/shiro](https://github.com/YOUR_ACCOUNT/shiro)
2. Click the new button called '**Compare & pull request**' that showed up just above the main area in your forked
repository
1. In your browser, navigate to your forked repository: [https://github.com/YOUR_ACCOUNT/shiro](https://github.com/YOUR_ACCOUNT/shiro)
2. Click the new button called '**Compare & pull request**' that showed up just above the main area in your forked repository
3. Validate the pull request will be into the upstream `main` and will be from your `feature_x` branch
4. Enter a detailed description of the work you have done and then click '**Send pull request**'

If you are requested to make modifications to your proposed changes, make the changes locally on your `feature_x`
branch, re-push the `feature_x` branch to your fork.
If you are requested to make modifications to your proposed changes, make the changes locally on your `feature_x` branch, re-push the `feature_x` branch to your fork.
The existing pull request should automatically pick up the change and update accordingly.


Cleaning up after a successful pull request
-------------------------------------------

Once the `feature_x` branch has been committed into the `upstream/main` branch, your local `feature_x` branch and
the `origin/feature_x` branch are no longer needed.
Once the `feature_x` branch has been committed into the `upstream/main` branch, your local `feature_x` branch and the `origin/feature_x` branch are no longer needed.
If you want to make additional changes, restart the process with a new branch.

> **IMPORTANT:** Make sure that your changes are in `upstream/main` before you delete your `feature_x`
> and `origin/feature_x` branches!
> **IMPORTANT:** Make sure that your changes are in `upstream/main` before you delete your `feature_x` and `origin/feature_x` branches!
You can delete these deprecated branches with the following:

Expand Down
Loading

0 comments on commit 4d6b274

Please sign in to comment.