Maven properties let you reuse values across your build, parent POMs, profiles, plugins, and CI commands. This guide organizes the major property types, shows how interpolation works, and gives practical commands to inspect effective values.
Originally published on 2010-04-14; fully revised and updated.

How Maven resolves properties
Maven interpolates property expressions (for example, values like ${project.version}) from multiple sources: the project model, parent model, settings, environment variables, JVM system properties, and user-defined values. In practice, this is what allows the same POM to behave correctly on local machines and CI agents.
flowchart TD
A[Read pom.xml] --> B[Load parent and super POM]
B --> C[Read active settings and profiles]
C --> D[Read JVM and environment values]
D --> E[Interpolate property expressions]
E --> F[Resolved values used by plugins and packaging]
The exact effective value can vary by active profile, command-line flags, and plugin behavior, so validation with Maven CLI commands is important before relying on a property in release automation.
Property sources compared
Use this as a quick decision table when choosing where a value should come from.
| Source | Example expression | Best used for | Notes |
|---|---|---|---|
| Built-in project location | ${basedir} | Relative paths in builds and plugins | Represents the directory containing pom.xml. |
| Project model (POM) | ${project.version} | Artifact naming and plugin configuration | ${pom.*} forms are commonly seen as aliases in older content. |
| Build directories | ${project.build.directory} | Output and generated files | Typically resolves to target unless overridden. |
| User settings | ${settings.localRepository} | Repository paths and user-scoped config | Loaded from user/global settings.xml. |
| Environment variables | ${env.M2_HOME} | Host-specific runtime paths | Depends on variable presence in the shell/agent environment. |
| Java system properties | ${java.home} | JVM/JDK-aware configuration | Comes from JVM system properties, not Maven POM fields. |
| Custom POM properties | ${my.filter.value} | Team-defined reusable constants | Defined under <properties> in POM. |
| Parent model values | ${project.parent.version} | Inheritance-aware builds | Useful in multi-module or corporate parent setups. |
| CLI user properties | -Dmy.filter.value=override | One-off overrides in CI/CD | Good for pipeline-specific toggles and temporary overrides. |
Frequently used property expressions
Project and build values
- ${basedir}
- ${project.name}
- ${project.version}
- ${project.build.directory}
- ${project.build.outputDirectory}
- ${project.build.finalName}
Settings, environment, and JVM values
- ${settings.localRepository}
- ${env.M2_HOME}
- ${java.version}
- ${java.home}
- ${user.home}
Parent POM values
Parent values are accessed through the project model (for example, ${project.parent.version}). For object-level context, the original post referenced the MavenProject API: org.apache.maven.project.MavenProject.
- ${project.parent.groupId}
- ${project.parent.artifactId}
- ${project.parent.version}
Define and override custom properties
Define team-owned values once in <properties>, then reference them throughout plugins, resources, and build metadata.
<project>
<properties>
<my.filter.value>hello</my.filter.value>
<artifact.suffix>internal</artifact.suffix>
</properties>
<build>
<finalName>${project.artifactId}-${project.version}-${artifact.suffix}</finalName>
</build>
</project>Code language: HTML, XML (xml)
You can override a custom property at runtime from the command line, which is common in CI pipelines.
mvn clean package -Dartifact.suffix=ci
Inspect effective values from the CLI
When in doubt, ask Maven directly for the evaluated result of a property expression.
mvn help:evaluate -Dexpression=project.version
mvn help:evaluate -Dexpression=project.build.directory
mvn help:evaluate -Dexpression=settings.localRepository
mvn help:evaluate -Dexpression=env.M2_HOME
To understand inherited values and profile effects, inspect the effective POM.
mvn help:effective-pomCode language: CSS (css)
Common pitfalls and best practices
- Prefer explicit
${project.*}expressions for readability in modern builds. - Do not assume environment variables exist on every developer machine or CI runner.
- Validate key properties with
help:evaluatebefore release or deployment jobs. - Use custom properties for team conventions, then allow CI overrides with
-Donly where needed. - Be careful with older aliases and legacy examples from Maven 2-era posts.
- In multi-module projects, confirm parent-derived values from the effective POM, not by assumption.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals