asmhatre/hibernate-demo
1
0
Fork 0
Code Activity

Add Hibernate 7 batches 2-6, batch 7, and batch 8: mapping styles, JPA annotations, natural IDs, @Immutable, stored procedures, in-memory test databases, JNDI mocking, proxies, associations, temporal mapping, named queries, HQL, Criteria API, EntityManager bootstrapping, Ehcache 3 L2 cache configuration, HikariCP connection pooling, Hibernate Validator CDI integration, aggregate functions, sorting, pagination, interceptors, and Hibernate Search 8 (Hibernate 7.4.5.Final + Spring Boot 4.1.1 + JDK 25)

Browse Source
This commit is contained in:
asmhatre
2026-09-20 06:06:42 +00:00
committed by Claude
commit 8568c0ce6c
330 changed files with 23668 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pom.xml
Executable
+235
View File
@@ -0,0 +1,235 @@
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>4.1.1</version>
<relativePath/>
</parent>
<groupId>com.ankurm</groupId>
<artifactId>hibernate-demo</artifactId>
<version>1.0.0</version>
<name>hibernate-demo</name>
<description>
Companion repository for the ankurm.com Hibernate 7 batch: get() vs load(), merge() vs
refresh(), and inserting objects efficiently.
</description>
<properties>
<java.version>25</java.version>
<!--
Spring Boot 4.1.0's own dependency management already resolves hibernate.version to
7.4.1.Final (checked in spring-boot-dependencies-4.1.0.pom before writing a line of code
here). This property is declared anyway, not to override anything, but so the pin is
visible in the POM and survives a future Boot patch release quietly bumping it under us.
See docs/00-versions.md for the two Boot releases (4.1.0 and 4.1.1) that resolve to two
different Hibernate patch versions from the same "4.1" line.
-->
<hibernate.version>7.4.5.Final</hibernate.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derbytools</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.github.h-thurow</groupId>
<artifactId>simple-jndi</artifactId>
<version>0.25.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>tools.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<!--
Chapter 20's constraint annotation and validator live in src/main (they're real
application classes, not test scaffolding), so the Bean Validation and CDI annotation
APIs they compile against need compile scope, not the test scope hibernate-validator-cdi
and weld-se-core use below (those two are only needed to actually RUN a CDI container).
jakarta.validation-api's version is managed by Boot 4.1.1's own BOM (3.1.1); the other two
are pinned to match what weld-se-core:6.0.4.Final resolves transitively.
-->
<groupId>jakarta.validation</groupId>
<artifactId>jakarta.validation-api</artifactId>
</dependency>
<dependency>
<groupId>jakarta.inject</groupId>
<artifactId>jakarta.inject-api</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>jakarta.enterprise.cdi-api</artifactId>
<version>4.1.0</version>
</dependency>
<dependency>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-jcache</artifactId>
</dependency>
<dependency>
<groupId>javax.cache</groupId>
<artifactId>cache-api</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>org.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>3.10.8</version>
<classifier>jakarta</classifier>
<exclusions>
<exclusion>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-community-dialects</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<!--
Used only by the raw, non-Spring StandardServiceRegistry bootstrap in chapter 19
(HikariCPConnectionProvider). Spring Boot itself needs no extra dependency for HikariCP;
spring-boot-starter-data-jpa already pulls in com.zaxxer:HikariCP transitively and
auto-configures a HikariDataSource bean whenever no other DataSource type is requested.
See docs/19-hikaricp-connection-pooling.md.
-->
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-hikaricp</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<!--
Chapter 20: CDI-based constructor/field injection into a ConstraintValidator. Version
pinned explicitly to 9.1.3.Final to match hibernate-validator itself, which Spring Boot
4.1.1's own BOM manages at that exact version (confirmed against
spring-boot-dependencies-4.1.1.pom); hibernate-validator-cdi is not itself in that BOM.
See docs/20-hibernate-validator-cdi.md.
-->
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator-cdi</artifactId>
<version>9.1.3.Final</version>
<scope>test</scope>
</dependency>
<dependency>
<!--
A standalone CDI container for chapter 20's tests; no Jakarta EE server involved.
Resolves jakarta.enterprise.cdi-api:4.1.0 transitively, which is the exact version
hibernate-validator-cdi:9.1.3.Final's own pom.xml requires (provided scope); verified
with a throwaway `mvn dependency:tree` before picking this version.
-->
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>6.0.4.Final</version>
<scope>test</scope>
</dependency>
<dependency>
<!--
The EL implementation matching jakarta.el-api:6.0.1, which weld-se-core:6.0.4.Final pulls
in as an API-only dependency; Weld needs a real implementation on the classpath too.
-->
<groupId>org.glassfish.expressly</groupId>
<artifactId>expressly</artifactId>
<version>6.0.0</version>
<scope>test</scope>
</dependency>
<dependency>
<!--
Chapter 25: full-text search on top of Hibernate ORM. Pinned to 8.4.0.Final, verified
against repo1.maven.org/.../hibernate-search-mapper-orm/maven-metadata.xml as the current
GA line, NOT the 7.3.2.Final this repo's blog post previously (and wrongly) claimed.
8.4.0.Final's own pom.xml depends on hibernate-core:7.4.0.Final, compatible with this
repo's pinned 7.4.5.Final (same major.minor line). @Indexed and its field annotations
live on a real entity in src/main, so this needs compile scope, not test scope.
-->
<groupId>org.hibernate.search</groupId>
<artifactId>hibernate-search-mapper-orm</artifactId>
<version>8.4.0.Final</version>
</dependency>
<dependency>
<!--
The Lucene backend, an embedded, local-filesystem index, no external search cluster
needed to run this chapter's tests. Same 8.4.0.Final line as the mapper above.
-->
<groupId>org.hibernate.search</groupId>
<artifactId>hibernate-search-backend-lucene</artifactId>
<version>8.4.0.Final</version>
<scope>runtime</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<!--
hibernate-jpamodelgen generates the static metamodel (Employee_, Department_) that
chapter 16's "true type safety" claim depends on. Wired as an annotation processor
path, not a plain dependency, so the generated sources land in
target/generated-sources/annotations and the metamodel classes are never hand-typed
or faked. If this stops generating them, the Criteria chapter's compile breaks
loudly instead of silently falling back to root.get("salary") everywhere.
-->
<annotationProcessorPaths>
<path>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${hibernate.version}</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
</plugins>
</build>
</project>