Introduction

This Axon classpath error means your application resolved conflicting framework artifacts, or mixed versions that were not meant to run together. The fix is usually in dependency management, not in manual classpath editing. You need the build tool to produce one compatible Axon set at runtime.

Why the Error Appears

Java applications rarely fail because a jar is literally missing from disk. They fail because the runtime classpath contains:

• more than one version of the same Axon module
• a starter that pulls one version while another module pins a different one
• an older transitive dependency hidden behind another library

The error text mentions org.axonframework.eventsourcing.eventstore.jpa, but the root cause is broader: the dependency graph is inconsistent.

Common symptoms include startup failures, NoSuchMethodError, ClassNotFoundException, or the explicit "single, compatible version" message.

Inspect the Dependency Graph First

Do not try random exclusions before you know what was selected. Ask Maven or Gradle for the runtime dependency graph.

For Maven:

mvn dependency:tree -Dincludes=org.axonframework

For Gradle:

./gradlew dependencies --configuration runtimeClasspath

If the output is large, focus on Axon modules and anything that brings them in transitively. You are looking for duplicate Axon artifacts with different versions, or a stale module that should not be present at all.

Gradle's dependencyInsight is especially helpful when one version wins silently and you need to know why:

./gradlew dependencyInsight \
  --dependency org.axonframework \
  --configuration runtimeClasspath

Align Axon Versions Centrally

Once you see version drift, stop pinning Axon modules independently. Manage them from one place so the framework stays internally consistent.

A Maven BOM is the cleanest option:

1<dependencyManagement>
2    <dependencies>
3        <dependency>
4            <groupId>org.axonframework</groupId>
5            <artifactId>axon-bom</artifactId>
6            <version>4.10.0</version>
7            <type>pom</type>
8            <scope>import</scope>
9        </dependency>
10    </dependencies>
11</dependencyManagement>
12
13<dependencies>
14    <dependency>
15        <groupId>org.axonframework</groupId>
16        <artifactId>axon-spring-boot-starter</artifactId>
17    </dependency>
18    <dependency>
19        <groupId>org.axonframework</groupId>
20        <artifactId>axon-eventsourcing</artifactId>
21    </dependency>
22</dependencies>

With this setup, the modules share a coordinated version line instead of competing with one another.

In Gradle, use the platform in the same spirit:

1dependencies {
2    implementation platform("org.axonframework:axon-bom:4.10.0")
3    implementation "org.axonframework:axon-spring-boot-starter"
4    implementation "org.axonframework:axon-eventsourcing"
5}

Exclude the Wrong Transitive Dependency

Sometimes the bad version enters through another library, not your direct dependencies. In that case, exclude the unwanted transitive module and let your centrally managed Axon version supply the right one.

Maven example:

1<dependency>
2    <groupId>com.example</groupId>
3    <artifactId>legacy-integration</artifactId>
4    <exclusions>
5        <exclusion>
6            <groupId>org.axonframework</groupId>
7            <artifactId>axon-eventsourcing</artifactId>
8        </exclusion>
9    </exclusions>
10</dependency>

This is better than trying to patch the runtime after packaging. The build should be deterministic before the application starts.

Be Careful with Spring Boot Starters

Spring Boot starters and Axon starters can simplify setup, but they also make version ownership easy to blur. Problems usually appear when a project:

• uses a starter for most Axon modules
• pins one Axon dependency manually in a feature module
• upgrades Boot or another starter without re-checking the graph

The rule is simple: pick one place to manage versions. If the BOM owns Axon versions, do not sprinkle explicit Axon versions across submodules.

Prove the Runtime Classpath Is Clean

After the build file changes, validate the result instead of trusting the edit.

Useful checks include:

1. rerun the dependency tree
2. rebuild from a clean state
3. inspect the packaged application if necessary

mvn clean package

or:

./gradlew clean build

If the same error survives after the graph looks clean, clear old caches or confirm that the deployment artifact matches the code you just built. IDE classpaths and packaged runtime classpaths are not always identical.

Common Pitfalls

• Pinning one Axon module version while the rest come from a different managed set.
• Looking only at direct dependencies and ignoring transitives.
• Mixing starter-managed versions with ad hoc explicit overrides.
• Fixing the build file but not rebuilding the real deployment artifact.
• Assuming the IDE classpath reflects the packaged runtime exactly.

Summary

• This error usually means Axon dependencies are misaligned on the runtime classpath.
• Inspect the dependency graph before making exclusions or upgrades.
• Manage Axon versions centrally with a BOM or platform.
• Exclude conflicting transitive dependencies instead of patching jars by hand.
• Rebuild and verify that only one compatible Axon version line remains.