Files

120 lines
4.9 KiB
XML

<?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>distributed-cache-demo</artifactId>
<version>1.0.0</version>
<name>distributed-cache-demo</name>
<properties>
<java.version>25</java.version>
<testcontainers.version>2.0.5</testcontainers.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-bom</artifactId>
<version>${testcontainers.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<!-- Hazelcast: embedded member + its Spring CacheManager adapter -->
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-spring</artifactId>
</dependency>
<!-- Infinispan: embedded Spring Boot 4 starter, confirmed to exist on
Maven Central under this exact artifactId (not guessed). Its
auto-configuration unconditionally registers an
InfinispanCacheMeterBinderProvider bean, whose
@Lookup-annotated method references
io.micrometer.core.instrument.binder.MeterBinder - a class
the starter itself does not pull in. Without micrometer-core
on the classpath this fails bean creation at startup with
NoClassDefFoundError, even when this profile is never
activated (the starter's auto-configuration runs regardless
of @Profile). Confirmed by reading the real stack trace, not
assumed from the starter's docs, which don't mention it. -->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-spring-boot4-starter-embedded</artifactId>
</dependency>
<!-- Redis: real server via Testcontainers, not embedded -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-testcontainers</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<!-- Infinispan's auto-configured embedded CacheManager registers
a JMX MBean under the fixed domain "org.infinispan" with no
per-instance disambiguation. That auto-configuration runs
unconditionally, in every Spring context this test JVM
creates, regardless of which profile is active - so with
Surefire's default of reusing one forked JVM across test
classes, the Hazelcast and Redis profile contexts each try
to register that same MBean domain a second/third time and
fail with ISPN000034 (confirmed from the real stack trace).
reuseForks=false gives each test class its own JVM, which
is the one reliable fix - there is no public toggle on
InfinispanEmbeddedConfigurationProperties to disable JMX. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<reuseForks>false</reuseForks>
</configuration>
</plugin>
</plugins>
</build>
</project>