Spring Data Commons is part of the umbrella Spring Data project that provides shared infrastructure across the Spring Data projects. It contains technology neutral repository interfaces as well as a metadata model for persisting Java classes.
-
Powerful Repository and custom object-mapping abstractions
-
Support for cross-store persistence
-
Dynamic query generation from query method names
-
Implementation domain base classes providing basic properties
-
Support for transparent auditing (created, last changed)
-
Possibility to integrate custom repository code
-
Easy Spring integration with custom namespace
This README as well as the reference documentation are the best places to start learning about Spring Data Commons.
The main project website contains links to basic project information such as source code, JavaDocs, Issue tracking, etc.
For more detailed questions, please refer to spring-data on stackoverflow. If you are new to Spring as well as to Spring Data, look for information about Spring projects.
Here are some ways for you to get involved in the community:
-
Create JIRA tickets for bugs and new features and comment and vote on the ones that you are interested in.
-
Github is for social coding: if you want to write code, we encourage contributions through pull requests from forks of this repository. If you want to contribute code this way, please reference a JIRA ticket as well covering the specific issue you are addressing.
-
Watch for upcoming articles on Spring by subscribing to springframework.org
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. If you forget to do so, you’ll be reminded when you submit a pull request. Active contributors might be asked to join the core team, and given the ability to merge pull requests.
Since this pipeline is purely Docker-based, it’s easy to:
-
Debug what went wrong on your local machine.
-
Test out a a tweak to your
test.shscript before sending it out. -
Experiment against a new image before submitting your pull request.
All of these use cases are great reasons to essentially run what the CI server does on your local machine.
|
Important
|
To do this you must have Docker installed on your machine. |
-
docker run -it --mount type=bind,source="$(pwd)",target=/spring-data-commons-github adoptopenjdk/openjdk8:latest /bin/bashThis will launch the Docker image and mount your source code at
spring-data-commons-github. -
cd spring-data-commons-githubNext, run your tests from inside the container:
-
./mvnw clean dependency:list test -Dsort(or whatever profile you need to test out)
Since the container is binding to your source, you can make edits from your IDE and continue to run build jobs.
If you need to test the build.sh script, do this:
-
docker run -it --mount type=bind,source="$(pwd)",target=/spring-data-commons-github adoptopenjdk/openjdk8:latest /bin/bashThis will launch the Docker image and mount your source code at
spring-data-commons-github. -
cd spring-data-commons-githubNext, try to package everything up from inside the container:
-
./mvnw -Pci,snapshot -Dmaven.test.skip=true clean deploy
|
Important
|
This will attempt to deploy to artifactory, but without credentials, it will fail, leaving you simply with a built artifact. |
|
Note
|
Docker containers can eat up disk space fast! From time to time, run docker system prune to clean out old images.
|