Introduction

A running Java application cannot read pom.xml magically unless that file is packaged or its contents are copied into some runtime-visible resource. The usual solution is not to parse pom.xml directly at runtime, but to let Maven inject the project version into a filtered resource or into the JAR manifest during the build.

Why Direct Runtime Parsing Is Usually The Wrong Goal

The pom.xml file is primarily a build-time artifact. It may not exist beside the deployed JAR, and even if it does, relying on its filesystem location is brittle.

That is why the practical approaches are:

• generate a properties resource during the build
• expose version info in the manifest
• read that generated runtime artifact from code

Option 1: Filter A Resource File

Create a resource such as version.properties.

app.version=${project.version}

Then enable Maven resource filtering in pom.xml.

1<build>
2  <resources>
3    <resource>
4      <directory>src/main/resources</directory>
5      <filtering>true</filtering>
6    </resource>
7  </resources>
8</build>

At build time, Maven replaces ${project.version} with the real version.

Read The Filtered Resource In Code

1import java.io.IOException;
2import java.io.InputStream;
3import java.util.Properties;
4
5public final class VersionInfo {
6    public static String getVersion() {
7        Properties props = new Properties();
8        try (InputStream in = VersionInfo.class.getResourceAsStream("/version.properties")) {
9            if (in == null) {
10                return "unknown";
11            }
12            props.load(in);
13            return props.getProperty("app.version", "unknown");
14        } catch (IOException ex) {
15            return "unknown";
16        }
17    }
18}

This is a simple, reliable way to surface the Maven version at runtime.

Option 2: Use The JAR Manifest

Another common technique is to write version information into the manifest and read it through the package metadata.

String version = VersionInfo.class.getPackage().getImplementationVersion();
System.out.println(version);

For this to work, the build must populate Implementation-Version in the manifest. This approach is elegant when your app is always run from a packaged JAR, but it may return null in IDE or test execution contexts unless the build setup provides the metadata there too.

Why This Is Better Than Parsing XML At Runtime

Parsing pom.xml directly creates unnecessary coupling between runtime code and build-layout assumptions. It also means your deployed application must still carry the build file in an accessible location.

Filtered resources or manifest metadata are more explicit because they turn the build-time version into a runtime contract.

Manifest Access Is Build-Context Sensitive

Reading Package#getImplementationVersion() is elegant when the code runs from a packaged artifact, but it can behave differently in tests, IDE launches, or exploded-class directories. That is why many teams prefer the filtered-resource approach for consistency across execution modes.

Common Use Cases

Runtime version access is useful for:

• startup logs
• diagnostics endpoints
• CLI --version output
• support and troubleshooting pages

In all of those cases, consistency matters more than cleverness. A build-injected value is exactly the right tool.

Common Pitfalls

The most common mistake is assuming pom.xml is automatically present in production at the same relative path as it was in the source tree. Another is using manifest version access and then being surprised when it returns null during IDE runs. Developers also often forget to enable resource filtering, which leaves literal ${project.version} text in the properties file. Finally, duplicating the version manually in a second config file defeats the purpose of using Maven as the source of truth.

Summary

• Do not treat pom.xml itself as a normal runtime input file.
• The usual solution is to inject the version into a resource or manifest during the Maven build.
• Filtered properties files are simple and reliable.
• Manifest version access is elegant when the app runs from a packaged JAR.
• Keep Maven as the single source of truth for the project version.