Skip to content

Latest commit

 

History

History
156 lines (118 loc) · 5.97 KB

CONTRIBUTING.adoc

File metadata and controls

156 lines (118 loc) · 5.97 KB
Raw

Contributing to the Neo4j Ecosystem

At Neo4j, we develop our software in the open at GitHub. This provides transparency for you, our users, and allows you to fork the software to make your own additions and enhancements. We also provide areas specifically for community contributions, in particular the neo4j-contrib space.

There’s an active Neo4j Online Community where we work directly with the community. If you’re not already a member, sign up!

We love our community and wouldn’t be where we are without you. Please remember: Many things are contributions, among them issues, code, documentation and examples.

If you’d like to open a pull-request, please be aware that we have to ask you to sign the Neo4j CLA before we are able to merge any code contributions. If you have questions about that, please let us know in the PR.

Building and compiling Neo4j-OGM Quarkus

You need Maven and JDK17+. To run all tests, a working Docker installation is required.

Build with

Clean and verify the project
./mvnw clean verify

Fast build

Note
 This is useful if you want to just have an install of a snapshot version. No tests are run, no verification is done.
Fast build (only compiling and producing packages)
./mvnw -Dfast package

Releasing (Only relevant for the current maintainers)

Releases will be created via standard Maven release:prepare / release:perform cycle. Tests might be skipped during the release steps with -DskipTestsDuringRelease and -DskipSigning.

Without Nexus staging plugin (and using Neo4j infrastructure)

./mvnw -DskipTestsDuringRelease release:prepare
./mvnw -DskipTestsDuringRelease -DskipSigning -DstagingRepository=releases::file:///`pwd`/target/artifacts release:stage

After that, Neo4j infrastructure must be applied accordingly.

With the Nexus staging plugin

In case there is direct access to the GPG signing key and also to the OSS Sonatype, the Nexus staging plugin can be added back to the parent pom:

<plugin>
    <groupId>org.sonatype.plugins</groupId>
    <artifactId>nexus-staging-maven-plugin</artifactId>
    <version>${nexus-staging-maven-plugin.version}</version>
    <extensions>true</extensions>
    <configuration>
        <serverId>ossrh</serverId>
        <nexusUrl>https://oss.sonatype.org/</nexusUrl>
        <autoReleaseAfterClose>true</autoReleaseAfterClose>
    </configuration>
</plugin>

With that in place, releasing can be done with:

./mvnw release:prepare
./mvnw release:perform

General considerations

Need to raise an issue?

Where you raise an issue depends largely on the nature of the problem.

Firstly, if you are an Enterprise customer, you might want to head over to our Customer Support Portal.

There are plenty of public channels available too, though. If you simply want to get started or have a question on how to use a particular feature, ask a question in Neo4j Online Community. If you think you might have hit a bug in our software (it happens occasionally!) or you have specific feature request then use the issue feature on the relevant GitHub repository. Check first though as someone else may have already raised something similar.

StackOverflow also hosts a ton of questions and might already have a discussion around your problem. Make sure you have a look there too.

Include as much information as you can in any request you make:

  • Which versions of our products are you using?

  • Which language (and which version of that language) are you developing with?

  • What operating system are you on?

  • Are you working with a cluster or on a single machine?

  • What code are you running?

  • What errors are you seeing?

  • What solutions have you tried already?

Want to contribute?

It’s easier for all of us if you try to follow these steps before creating a pull request:

  • Do all your work in a personal fork of the original repository

  • Rebase, don’t merge (we prefer to keep our history clean)

  • Create a branch (with a useful name) for your contribution

  • Make sure you’re familiar with the appropriate coding style (this varies by language so ask if you’re in doubt)

  • Include unit tests if appropriate (obviously not necessary for documentation changes)

Note
 Small things that doesn’t change the public API or documented behaviour and of course bug fixes usually go in quickly. If you want to add new features with public API changes or additions or want to customize or change a feature, please do reach out to us on one of the available channels, preferable by creating a new issue first in which we can discuss the proposed changes.

We can’t guarantee that we’ll accept pull requests and may ask you to make some changes before they go in. Occasionally, we might also have logistical, commercial, or legal reasons why we can’t accept your work, but we’ll try to find an alternative way for you to contribute in that case. Remember that many community members have become regular contributors and some are now even Neo employees!

Further reading

If you want to find out more about how you can contribute, head over to our website for more information.

Got an idea for a new project?

If you have an idea for a new tool or library, start by talking to other people in the community. Chances are that someone has a similar idea or may have already started working on it. The best software comes from getting like minds together to solve a problem. And we’ll do our best to help you promote and co-ordinate your Neo ecosystem projects.