If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/spring-projects/spring-data-examples shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 5w ago
• 11 active contributors
• Distributed ownership (top contributor 46% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live spring-projects/spring-data-examples repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/spring-projects/spring-data-examples.

What it runs against: a local clone of spring-projects/spring-data-examples — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in spring-projects/spring-data-examples | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 68 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of spring-projects/spring-data-examples. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/spring-projects/spring-data-examples.git
#   cd spring-data-examples
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of spring-projects/spring-data-examples and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "spring-projects/spring-data-examples(\\.git)?\\b" \\
  && ok "origin remote is spring-projects/spring-data-examples" \\
  || miss "origin remote is not spring-projects/spring-data-examples (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.adoc" \\
  && ok "README.adoc" \\
  || miss "missing critical file: README.adoc"
test -f "bom/pom.xml" \\
  && ok "bom/pom.xml" \\
  || miss "missing critical file: bom/pom.xml"
test -f "cassandra/example/src/main/java/example/springdata/cassandra/basic/BasicUserRepository.java" \\
  && ok "cassandra/example/src/main/java/example/springdata/cassandra/basic/BasicUserRepository.java" \\
  || miss "missing critical file: cassandra/example/src/main/java/example/springdata/cassandra/basic/BasicUserRepository.java"
test -f ".github/workflows/build.yaml" \\
  && ok ".github/workflows/build.yaml" \\
  || miss "missing critical file: .github/workflows/build.yaml"
test -f "cassandra/aot-optimization/src/main/java/example/springdata/cassandra/AotApplication.java" \\
  && ok "cassandra/aot-optimization/src/main/java/example/springdata/cassandra/AotApplication.java" \\
  || miss "missing critical file: cassandra/aot-optimization/src/main/java/example/springdata/cassandra/AotApplication.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 68 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~38d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/spring-projects/spring-data-examples"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A monorepo of runnable examples for Spring Data modules (JPA, JDBC, MongoDB, Elasticsearch, Cassandra, etc.) demonstrating practical usage patterns, query APIs, and advanced features. It serves as a living reference showing how to use Spring Data repositories, templates, and reactive stacks across different database backends—not tutorials, but actual working code you can clone and run immediately. Multi-module monorepo organized by Spring Data variant: cassandra/, elasticsearch/, jdbc/, jpa/, mongodb/, neo4j/, r2dbc/ directories, each containing module-specific examples (basic/, example/, reactive/, aot-optimization/). A shared bom/ module manages version alignment. Each example is a standalone Maven/Gradle project with pom.xml and complete src/main/java application code.

Spring framework developers integrating data access layers who need concrete, copy-paste-ready examples of repository patterns, custom queries, and database-specific features. Also used by Spring Data maintainers as a reference implementation and testing ground for new capabilities.

Actively maintained and production-grade. CI/CD via GitHub Actions (.github/workflows/build.yaml, project.yml), Maven wrapper configured, Travis CI integration visible. The repo tracks current Spring versions (5.3.9, Spring Data 2021.0.4) and has examples for cutting-edge features like AOT optimization and GraalVM native images, indicating ongoing investment.

Low risk for a reference repo; it's not a library but examples. Main risks: examples may lag behind latest Spring Data releases if not updated regularly, and multi-module structure means a breaking change in one Spring Data module (MongoDB, Cassandra, JPA) requires coordinating updates across several example folders. No apparent single-maintainer risk (Spring official project).

Active development visible: AOT optimization examples for Cassandra, JDBC, and JPA (advanced ahead-of-time compilation for GraalVM), vector search examples for Cassandra, reactive examples across modules, and GraalVM native image compilation support (jdbc/graalvm-native/). Workflow files indicate continuous integration on pushes.

Clone the repo, pick a module (e.g., jpa/example for JPA), cd into it, and run: mvn clean install && mvn spring-boot:run. Maven wrapper is pre-configured (.mvn/wrapper/), so no JDK version worries. For Gradle-based modules (bom/), use ./gradlew build.

Daily commands: For Maven projects: mvn clean install; mvn spring-boot:run. For Gradle projects (bom/): ./gradlew build; ./gradlew bootRun. Cassandra, MongoDB, and Elasticsearch examples require local service instances (docker run recommended). Check individual module READMEs (e.g., cassandra/example/README.adoc) for service startup instructions.

• README.adoc — Primary entry point documenting all example modules and their purposes across Spring Data ecosystems.
• bom/pom.xml — Bill of Materials defining consistent Spring Data and Spring Framework versions across all examples.
• cassandra/example/src/main/java/example/springdata/cassandra/basic/BasicUserRepository.java — Foundational Spring Data Cassandra repository pattern that all Cassandra examples extend from.
• .github/workflows/build.yaml — CI/CD pipeline ensuring all examples build and pass integration tests on every commit.
• cassandra/aot-optimization/src/main/java/example/springdata/cassandra/AotApplication.java — Demonstrates modern AOT compilation patterns for Spring Data, critical for GraalVM native image adoption.
• cassandra/example/src/main/java/example/springdata/cassandra/convert/ConverterConfiguration.java — Shows custom type conversion setup, a key pattern repeated across multiple Spring Data modules.
• bom/build.gradle — Gradle build configuration providing the build orchestration model for all examples.

Add a new Spring Data Cassandra example module

1. Create directory structure mirroring cassandra/example with pom.xml inheriting from parent (cassandra/{new-example}/pom.xml)
2. Define domain entity with @Table and @PrimaryKey annotations (cassandra/{new-example}/src/main/java/example/springdata/cassandra/YourEntity.java)
3. Create repository interface extending CrudRepository<YourEntity, KeyType> (cassandra/{new-example}/src/main/java/example/springdata/cassandra/YourEntityRepository.java)
4. Configure Spring context with @EnableCassandraRepositories and cluster settings (cassandra/{new-example}/src/main/java/example/springdata/cassandra/CassandraConfiguration.java)
5. Write integration test extending AbstractCassandraTests or using embedded Cassandra (cassandra/{new-example}/src/test/java/example/springdata/cassandra/YourEntityRepositoryTests.java)

Add custom type conversion for Cassandra entities

1. Create domain entities requiring custom mapping (cassandra/example/src/main/java/example/springdata/cassandra/convert/CustomType.java)
2. Implement Converter<Source, Target> for bidirectional conversion (cassandra/example/src/main/java/example/springdata/cassandra/convert/CustomTypeConverter.java)
3. Register converters in @Configuration using CassandraCustomConversions (cassandra/example/src/main/java/example/springdata/cassandra/convert/ConverterConfiguration.java)
4. Test converter with integration test loading Spring context (cassandra/example/src/test/java/example/springdata/cassandra/convert/CustomTypeConverterTest.java)

Add entity lifecycle event handling

1. Create event listener bean implementing AbstractCassandraEventListener<T> (cassandra/example/src/main/java/example/springdata/cassandra/events/CustomEventListener.java)
2. Override onBeforeSave(), onAfterSave(), onBeforeDelete() methods as needed (cassandra/example/src/main/java/example/springdata/cassandra/events/CustomEventListener.java)
3. Register listener as @Bean in configuration class (cassandra/example/src/main/java/example/springdata/cassandra/events/BasicConfiguration.java)
4. Verify event firing with integration test (cassandra/example/src/test/java/example/springdata/cassandra/events/CustomEventListenerTest.java)

Publish new example version to GitHub

1. Update module description in root README.adoc (README.adoc)
2. Ensure all tests pass locally and via GitHub Actions (.github/workflows/build.yaml)
3. Verify BOM versions are stable and documented (bom/pom.xml)
4. Create pull request with example module and test coverage (.github/PULL_REQUEST_TEMPLATE.md)

• Spring Data — Provides abstraction layer over Cassandra CQL, reducing boilerplate and enabling portable repository patterns across different backends.
• Apache Cassandra — Distributed, highly available NoSQL database; examples showcase partitioning, replication, and CQL query patterns specific to Cassandra.
• Maven/Gradle with BOM — Multi-module builds with centralized dependency management ensure consistent Spring Framework and Spring Data versions across all examples.
• GitHub Actions — Cloud-native CI/CD eliminates build environment drift and provides visible integration test results for pull requests.
• GraalVM AOT — Demonstrates native image compilation for Spring Data, addressing startup time and memory concerns in containerized deployments.

• Embedded Cassandra for testing vs. Docker Compose

  • Why: Embedded Cassandra reduces external dependencies and CI environment setup complexity, enabling fast developer iteration.
  • Consequence: Embedded Cassandra is lighter-weight but may not catch platform-specific issues; production deployments should use proper Cassandra clusters.

• Single monorepo for all Spring Data modules vs. separate repos

  • Why: Centralized versioning, easier cross-module examples, and unified build pipeline reduce maintenance overhead.
  • Consequence: Repository grows large (600+ files); clone and build times increase; changes to one module may trigger full test suite.

• AsciiDoc (README.adoc) over Markdown

  • Why: AsciiDoc supports complex formatting, cross-references, and embedded code blocks better suited for technical documentation.
  • Consequence: Higher barrier to entry for casual contributors; requires AsciiDoc tooling knowledge.

• JUnit 4/5 with TestContainers for integration tests

  • Why: Standard Spring testing patterns with lifecycle management and reproducible embedded databases.
  • Consequence: Tests are integration-level only; unit tests with mocks are minimal, so refactoring confidence depends on integration coverage.

Database services must run locally: Cassandra, MongoDB, Elasticsearch, and Neo4j examples require Docker instances or local installs (not auto-provisioned). Application.properties files assume localhost:default-port connectivity. Maven wrapper in .mvn/ expects JAVA_HOME set correctly. Gradle examples use gradle/wrapper/ but require gradlew bash script execution (Windows: gradlew.bat). Older examples may reference Spring Data versions from 2021.0.4 and may conflict if you're using a newer Boot version locally.

• Spring Data Repository Pattern — The core abstraction of this entire repo; understanding CrudRepository, PagingAndSortingRepository, and custom @Query methods is essential to using any example
• Query Derivation (Method Name Query Generation) — Spring Data infers queries from method names like findByLastNameAndFirstName(); examples across all modules rely on this zero-boilerplate pattern
• Reactive Streams (Project Reactor) — Non-blocking data access; every module has a reactive/ subfolder using Mono/Flux for async queries—core to modern Spring Data
• Ahead-Of-Time (AOT) Compilation & GraalVM Native Image — aot-optimization/ and graalvm-native/ examples show how Spring Data repositories work in compiled native binaries with zero reflection; critical for microservices and edge deployment
• Spring Data Auditing — cassandra/example/src/main/java/example/springdata/cassandra/auditing/ and similar folders show automatic createdDate/lastModifiedDate management—reduces boilerplate entity code
• Persistence Callback Lifecycle (@PrePersist, @PostLoad) — JPA entity examples demonstrate lifecycle hooks for validation and transformation; recurring pattern across relational and document examples
• Bill-of-Materials (BOM) Dependency Management — bom/pom.xml coordinates versions across all Spring Data modules; understanding Maven BOM imports prevents version conflicts when adding new modules

• spring-projects/spring-data-jpa — The upstream library that jpa/ examples demonstrate; go here to understand implementation details and file issues
• spring-projects/spring-data-commons — Core abstractions (Repository interface, CrudRepository) shared across all Spring Data modules featured in this examples repo
• spring-projects/spring-boot — Auto-configuration engine that every example relies on; spring-boot:run plugin drives the executable examples
• spring-projects/spring-framework — Foundational IoC/AOP framework powering Spring Data dependency injection and transaction management in all examples
• graalvm/graalvm-demos — Companion repo showing native image compilation; jdbc/graalvm-native/ and aot-optimization/ examples use GraalVM techniques from here

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for Cassandra AOT optimization example

The cassandra/aot-optimization module exists with core classes (Address.java, User.java, UserRepository.java, AotApplication.java) but has no visible test directory. AOT optimization is a critical Spring feature for native image compilation, and demonstrating it with comprehensive tests would help contributors understand expected behavior and validate their own AOT configurations. This is especially valuable since AOT has complex build-time requirements.

• [ ] Create cassandra/aot-optimization/src/test/java directory structure
• [ ] Add tests for AotApplication startup and basic repository operations
• [ ] Add tests verifying AOT hints are correctly generated (using Spring AOT testing utilities)
• [ ] Document test execution requirements in cassandra/aot-optimization/README.adoc
• [ ] Validate tests pass with both JVM and native image builds

Complete and document the vector-search example in cassandra module

The README.adoc references 'cassandra/vector-search' with incomplete documentation ('Example how to do vector search with' - text cuts off). The partial file structure shows this is a planned example but appears incomplete. Vector search is an emerging feature in modern data stores, and a complete, documented example would be highly valuable for users wanting to implement semantic search or RAG patterns.

• [ ] Create or complete cassandra/vector-search/pom.xml with Spring Data Cassandra and vector dependencies
• [ ] Implement example classes showing vector embedding storage and similarity queries
• [ ] Create cassandra/vector-search/README.adoc with clear use case explanation and code walkthrough
• [ ] Add src/test directory with integration tests for vector similarity search operations
• [ ] Update root README.adoc to complete the vector-search description

Add missing README and documentation for cassandra/example submodules

The cassandra/example directory contains multiple feature-specific packages (auditing, basic, convert, events, optimisticlocking, projection) but no individual README files explaining each pattern. Contributors navigating this module won't understand which example to study for their use case. Each submodule addresses a distinct Spring Data pattern and deserves clear documentation with code snippets and configuration explanations.

• [ ] Create cassandra/example/src/main/java/example/springdata/cassandra/auditing/README.adoc explaining AuditedPerson auditing pattern
• [ ] Create cassandra/example/src/main/java/example/springdata/cassandra/convert/README.adoc documenting custom converters with examples
• [ ] Create cassandra/example/src/main/java/example/springdata/cassandra/events/README.adoc showing entity lifecycle events
• [ ] Create cassandra/example/src/main/java/example/springdata/cassandra/optimisticlocking/README.adoc comparing SimplePerson vs OptimisticPerson approaches
• [ ] Create cassandra/example/src/main/java/example/springdata/cassandra/projection/README.adoc with CustomerProjection usage examples
• [ ] Update cassandra/example/README.adoc with navigation guide linking to all submodule documentation

• Add a vector-search example for MongoDB (cassandra/vector-search/ exists but MongoDB equivalent is missing) to demonstrate similarity search parity across modules
• Document GraalVM native image build steps for remaining modules (JDBC has graalvm-native/, but MongoDB and JPA examples lack explicit native compilation examples with build instructions)
• Add a composite example showing multi-datasource setup for Elasticsearch + MongoDB (jpa/multiple-datasources/ exists for JPA, but no cross-module example) to show federation patterns

This Spring Data examples repository has moderate security concerns primarily related to significantly outdated dependencies (Spring Framework 5.3.9 and Spring Data BOM 2021.0.4 from 2021). These versions likely contain multiple known CVEs. The project uses deprecated Gradle configurations and lacks explicit dependency version pinning, increasing supply chain risk. As an example repository, there's inherent risk of insecure patterns being propagated. Immediate action is required to update all dependencies to current stable versions and implement dependency security scanning in the CI/CD pipeline.

• High · Outdated Spring Framework Version — build.gradle (springVersion = '5.3.9'). The build.gradle file specifies Spring Framework version 5.3.9, which is significantly outdated (released in 2021). This version likely contains multiple known security vulnerabilities that have been patched in newer releases. Fix: Update to the latest stable Spring Framework 6.x or 5.3.x patch version. Review Spring Security advisories at https://spring.io/security/advisories and apply patches accordingly.
• High · Outdated Spring Data BOM Version — build.gradle (springDataVersion = '2021.0.4'). The Spring Data BOM version 2021.0.4 is outdated (from 2021). This BOM manages multiple Spring Data modules which may contain known security vulnerabilities. Fix: Update to the latest Spring Data BOM version (2024.x or current stable release). Verify all transitive dependencies are patched for known CVEs.
• Medium · Use of Deprecated Gradle Dependency Configuration — build.gradle (compile dependencies). The build.gradle uses 'compile' configuration which is deprecated in Gradle 7.0+. This may indicate the project uses an older Gradle version or hasn't been properly updated, potentially missing security-related build improvements. Fix: Replace 'compile' with 'implementation' configuration. Update Gradle to version 8.x. Review and update all plugins and build configurations.
• Medium · Missing Dependency Management for Transitive Dependencies — build.gradle (dependencies section). The build.gradle imports Maven BOMs but doesn't explicitly declare or lock versions for direct dependencies. This could lead to unexpected transitive dependency versions containing security vulnerabilities. Fix: Use Gradle dependency lock files or explicit version constraints. Run 'gradle dependencies' to audit transitive dependencies and use tools like OWASP Dependency-Check to identify vulnerable versions.
• Low · Example Projects May Contain Unvalidated Configurations — cassandra/example and all example modules. This is an example repository. Without examining source code, there's a risk that example code may contain insecure practices (hardcoded credentials, missing validation, etc.) that could be copied into production applications. Fix: Add security-focused documentation and comments to examples. Include unit tests demonstrating secure patterns. Avoid including any real credentials or sensitive data in examples.
• Low · Travis CI Configuration May Be Outdated — .travis.yml. The .travis.yml file indicates use of Travis CI for CI/CD. Modern GitHub-hosted projects typically migrate to GitHub Actions, and Travis CI configuration may be stale or no longer actively maintained. Fix: Migrate to GitHub Actions (.github/workflows already present). Ensure security scanning is integrated into CI/CD pipeline (SAST, dependency scanning, container scanning if applicable).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.