Skip to content

Latest commit

 

History

History
109 lines (73 loc) · 5.2 KB

CONTRIBUTING.md

File metadata and controls

109 lines (73 loc) · 5.2 KB

Contributor License

If this is your first time contributing to an Eclipse Foundation project, you'll need to sign the Eclipse Contributor Agreement.

Issues

Search the issue tracker for a relevant issue or create a new one.

Making changes

Fork the repository in GitHub and make changes in your fork.

Please add a description of your changes to the draft release notes.

Finally, submit a pull request.

Details on working with GitHub for Eclipse Collections is located at the Wiki.

Contact us

Join the mailing list and email the community at collections-dev@eclipse.org to discuss your ideas and get help.

Build

The Eclipse Collections build requires below as dependencies.

  • Java 11+
  • Maven 3.1.0+

The Eclipse Collections build performs code generation to create primitive collections. Run the full build once before opening your IDE.

mvn install -DskipTests=true

Now you can open the project in your IDE and it won't complain about missing files. You'll be able to use the IDE to perform incremental builds and run tests. You should rarely need to run the maven build, except when:

Semantic Versioning

Eclipse Collections version numbers follow Semantic Versioning. This means we increment the major version when we make incompatible API changes. This includes any changes which

  • break binary compatibility
  • break source compatibility
  • break serialization compatibility

Normally, collections will have the same serialized form across major releases, indefinitely. But if we have to break serialization for some reason, it will be in a major release. Eclipse Collections includes a suite of serialization tests to prevent accidental changes.

While preparing a minor release, the master branch won't contain any compatibility breaking changes. Feel free to work on major, compatibility-breaking changes whenever you'd like. However, if you submit a pull request to master while we're preparing a minor release, you'll have to be patient and you'll need to rebase your changes once the release is complete.

Coding Style

Eclipse Collections follows a coding style that is similar to Google's Style Guide for Java, but with curly braces on their own lines. Many aspects of the style guide are enforced by CheckStyle, but not all, so please take care.

mvn clean install checkstyle:check --projects "!scala-unit-tests,!jmh-scala-tests,!jmh-tests" -DskipTests=true

Avoid changing whitespace on lines that are unrelated to your pull request. This helps preserve the accuracy of the git blame view, and makes code reviews easier.

Commit messages

Pull requests

Excessive branching and merging can make git history confusing. With that in mind

Submit your pull request when ready. Three checks will be kicked off automatically.

  • IP Validation: Checks that all committers signed the Eclipse CLA and signed their commits.
  • Continuous integration: GitHub Actions that run JUnit tests, CheckStyle, and FindBugs.
  • The standard GitHub check that the pull request has no conflicts with the base branch.

Make sure all the checks pass. One of the committers will take a look and provide feedback or merge your contribution.

That's it! Thanks for contributing to Eclipse Collections!