Merge pull request #66 from lvjing2/youji-dev-1

【arklet】add license auto generator and auto formatter and checker

.github/workflows/arklet_unit_test.yml

@@ -48,7 +48,12 @@ jobs:
           key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
 
       - name: Test
-        run: mvn test
+        run: mvn clean install -DskipTests -Dmaven.javadoc.skip=true -B -U
+          && sh ./check_format.sh
+          && mvn test
+
+      - name: Codecov
+        uses: codecov/codecov-action@v1
 
       - name: Setup Java JDK
         uses: actions/[email protected]
@@ -57,4 +62,6 @@ jobs:
           java-version: 17
 
       - name: Test
-        run: mvn test
+        run: mvn clean install -DskipTests -Dmaven.javadoc.skip=true -B -U
+          && sh ./check_format.sh
+          && mvn test

.github/workflows/codecov.yml

@@ -0,0 +1,53 @@
+- name: Codecov
+  # You may pin to the exact commit or the version.
+  # uses: codecov/codecov-action@f32b3a3741e1053eb607407145bc9619351dc93b
+  uses: codecov/[email protected]
+  with:
+    # Repository upload token - get it from codecov.io. Required only for private repositories
+    token: # optional
+    # Comma-separated list of files to upload
+    files: # optional
+    # Directory to search for coverage reports.
+    directory: # optional
+    # Flag upload to group coverage metrics (e.g. unittests | integration | ui,chrome)
+    flags: # optional
+    # The commit SHA of the parent for which you are uploading coverage. If not present, the parent will be determined using the API of your repository provider.  When using the repository providers API, the parent is determined via finding the closest ancestor to the commit.
+    commit_parent: # optional
+    # Don't upload files to Codecov
+    dry_run: # optional
+    # Environment variables to tag the upload with (e.g. PYTHON | OS,PYTHON)
+    env_vars: # optional
+    # Specify whether or not CI build should fail if Codecov runs into an error during upload
+    fail_ci_if_error: # optional
+    # Path to coverage file to upload
+    file: # optional
+    # Comma-separated list, see the README for options and their usage
+    functionalities: # optional
+    # Move discovered coverage reports to the trash
+    move_coverage_to_trash: # optional
+    # User defined upload name. Visible in Codecov UI
+    name: # optional
+    # Specify the branch name
+    override_branch: # optional
+    # Specify the build number
+    override_build: # optional
+    # Specify the commit SHA
+    override_commit: # optional
+    # Specify the pull request number
+    override_pr: # optional
+    # Specify the git tag
+    override_tag: # optional
+    # Override the assumed OS. Options are alpine | linux | macos | windows.
+    os: # optional
+    # Used when not in git/hg project to identify project root directory
+    root_dir: # optional
+    # Specify the slug manually (Enterprise use)
+    slug: # optional
+    # Change the upload host (Enterprise use)
+    url: # optional
+    # Specify whether the Codecov output should be verbose
+    verbose: # optional
+    # Specify which version of the Codecov Uploader should be used. Defaults to `latest`
+    version: # optional
+    # Directory in which to execute codecov.sh
+    working-directory: # optional

.gitignore

@@ -1,4 +1,4 @@
-
+vendor
 target/
 *.iml
 .idea/
@@ -8,3 +8,4 @@ pom.xml.bak
 .classpath
 *.log
 logs/
+.flattened-pom.xml

CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,39 @@
+
+## Contributing to SOFAArk
+SOFAArk is released under the Apache 2.0 license, and follows a very
+standard Github development process, using Github tracker for issues and
+merging pull requests into master . If you would like to contribute something, 
+or simply want to hack on the code this document should help you get started.
+
+### Sign the Contributor License Agreement
+Before we accept a non-trivial patch or pull request we will need you to 
+sign the Contributor License Agreement. Signing the contributor’s agreement 
+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. Active contributors might be asked to join the core team, and given 
+the ability to merge pull requests.
+
+### Code Conventions
+None of these is essential for a pull request, but they will all help. 
+
+1. we provided a [code formatter file](./Formatter.xml), it will formatting automatically your project when during process of building. We would check code format when run ci test, so please ensure that you have built project before you push branch.
+
+2. Make sure all new `.java` files to have a simple Javadoc class comment 
+with at least an `@author` tag identifying you, and preferably at least a 
+paragraph on what the class is for.
+
+3. Add the ASF license header comment to all new `.java` files (copy from existing files in the project)
+
+4. Add yourself as an `@author` to the `.java` files that you modify substantially (more than cosmetic changes).
+
+5. Add some Javadocs.
+
+6. A few unit tests would help a lot as well — someone has to do it.
+
+7. When writing a commit message please follow [these conventions](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), if 
+you are fixing an existing issue please add Fixes gh-XXXX at the end 
+of the commit message (where XXXX is the issue number).
+
+8. Ensure that code coverage does not decrease。
+
+9. Contribute a PR as the rule of Gitflow Workflow; SOFAArk's version contains three digit, the first one is for compatibility; the second one is for new features and enhancement; the last one is for bug fix.

README.md

@@ -1,3 +1,8 @@
+[![Coverage Status](https://codecov.io/gh/sofastack/sofa-serverless/branch/master/graph/badge.svg)](https://codecov.io/gh/sofastack/sofa-serverless/branch/master/graph/badge.svg)
+![license](https://img.shields.io/badge/license-Apache--2.0-green.svg)
+
+[//]: # (![maven](https://img.shields.io/nexus/r/https/oss.sonatype.org/com.alipay.sofa/sofa-ark-all.svg))
+
 Welcome to SOFAServerless open source comminity. SOFAServerless is a modularization application architecture patterns for company business rapid development, operation, evolution and cooperation with low cost. Please watch us or join us in DingDing Group: 24970018417 .
 
 欢迎来到 SOFAServerless 开源社区。SOFAServerless 是一种模块化的应用架构模式，能够帮助大中小企业低成本地实现极速研发、运维、微服务演进和人员协作，从而为企业实现降本增效。欢迎加入钉钉群关注我们或者与我们一起共建面向普通应用低成本接入的 Serverless 解决方案。钉钉群号：24970018417 。