Skip to content

Latest commit

 

History

History
148 lines (94 loc) · 6.41 KB

CONTRIBUTING.adoc

File metadata and controls

148 lines (94 loc) · 6.41 KB
Raw

Contributing to Jakarta Data

Table of Contents

Thanks for your interest in this project.

Project description

Jakarta Data provides an API that makes data access easy. A Java developer can split the persistence from the model with several features, such as the ability to compose custom query methods on a Repository interface where the framework will implement it.

References:

Terms of Use

This repository is subject to the Terms of Use of the Eclipse Foundation

Developer resources

Information regarding source code management, builds, coding standards, and more.

The project maintains the following source code repositories

Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation Development Process and operates under the terms of the Eclipse IP Policy.

The Jakarta EE Specification Committee has adopted the Jakarta EE Specification Process (JESP) in accordance with the Eclipse Foundation Specification Process v1.2 (EFSP) to ensure that the specification process is complied with by all Jakarta EE specification projects.

Eclipse Contributor Agreement

In order to be able to contribute to Eclipse Foundation projects you must electronically sign the Eclipse Contributor Agreement (ECA).

The ECA provides the Eclipse Foundation with a permanent record that you agree that each of your contributions will comply with the commitments documented in the Developer Certificate of Origin (DCO). Having an ECA on file associated with the email address matching the "Author" field of your contribution’s Git commits fulfills the DCO’s requirement that you sign-off on your contributions.

For more information, please see the Eclipse Committer Handbook: https://www.eclipse.org/projects/handbook/#resources-commit

Contact

Contact the project developers via the project’s "dev" list.

Developer Certificate of Origin - DCO

This is a security layer for the project and for the developers. It is mandatory.

Follow one of these two methods to add DCO to your commits:

1. Command line

Follow the steps: Step 1: Configure your local git environment adding the same name and e-mail configured at your GitHub account. This helps to sign commits manually during reviews and suggestions.

git config --global user.name “Name”
git config --global user.email “[email protected]”

Step 2: Add the Signed-off-by line with the '-s' flag in the git commit command:

$ git commit -s -m "This is my commit message"

2. GitHub website

You can also manually sign your commits during GitHub reviews and suggestions, follow the steps below:

Step 1: When the commit changes box opens, manually type or paste your signature in the comment box, see the example:

Signed-off-by: Name < e-mail address >

Contact

Contact the project developers via the project’s "dev" list.

Issues

If you found a bug or have an idea, check out the following sections before submitting your contribution.

Check the issue tracker

Because all of our issues are centralized in our main repository, it is quite likely that you will find a similar topic that is being discussed. Check the open issues. Another good way to start is good first issues.

Types of Commits:

  • fix: Any commit that patches a bug anywhere in the codebase

  • feat: Any commit that introduces a new feature or focuses on enhancing the scope of existing features

  • breaking changes: Any commit that has a footer "BREAKING CHANGE", or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. Breaking changes are discouraged and should generally be avoided if possible due to their adverse impacts on users.

  • other than fix and feat: Any commit that consists of the following keywords: build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others. For other keywords refer to @commitlint/config-conventional (based on the Angular convention)

  • other footers:<description> may be provided and follow a convention similar to git trailer format

Examples of commits

  • Regular Commit Message: This may be used for either fix or feat and can be written as fix: <message> or feat: <message>

  • Commit with breaking change: Example: A new feature being introduced as a breaking change can be written as feat!: <message>, this can also simply be written as a regular feat with the BREAKING CHANGE appended to it at the end of the commit

  • Specific breaking change:: Example: A breaking change introduced with a new feature somewhere in the api can be written as feat(api)!: <message>

  • Changing the docs: docs: <message>

  • Regular commit message with specification: A new feature introduced in the api can be written as feat(api): <message>

Formatting Commit messages

All commit messages must clearly state the change that takes place. Multiple paragraphs or bullet points explaining the changes in detail are encouraged. The message must contain the link to the issue that it is directed towards. If there are other people working on a particular issue which you wanted to work on as well, consider working together. If the commit influences a visual change, screenshots are encouraged