skip to content

Walk through the built-in property families Maven exposes (project.*, settings.*, env.*, system) and give a concrete use for each.

level: middleimportance: should knowfreq 45%

answer

  1. project.* = POM model
  2. settings.* = settings.xml
  3. env.* = OS env vars
  4. ${java.version} = JVM runtime, not your <java.version>
  5. -D system props win

basics

~10 s

project.* reads the POM (like ${project.version}); settings.* reads settings.xml; env.* reads OS environment variables; system/JVM properties come from -D and the runtime. Each gives access to build context without hardcoding values.

solid answer

~40 s

Maven exposes several built-in property namespaces. project.* maps to the effective POM model — ${project.version}, ${project.artifactId}, ${project.build.directory} (target), ${project.basedir} — used everywhere from filtering to plugin config. settings.* reads from settings.xml, e.g. ${settings.localRepository} for the local repo path. env.* surfaces OS environment variables like ${env.HOME} or ${env.CI}. System/JVM properties cover ${java.version}, ${user.home}, and anything passed with -Dkey=value. Knowing these lets you stamp build metadata into resources, configure plugins relative to target, and adapt behavior to CI or environment without hardcoding paths. A subtle point: ${java.version} as a system property is the JVM runtime version, distinct from a user-defined <java.version> property you might set for the compiler.

code

bash · 2 lines
bash
mvn help:evaluate -Dexpression=project.build.directory -q -DforceStdout
mvn help:evaluate -Dexpression=settings.localRepository -q -DforceStdout

go deeper

for a junior

Recognizes ${project.version} and that built-ins exist.

for a middle

Can list project./settings./env.*/system and give a use for each.

for a senior

Uses help:evaluate to debug resolution and knows precedence subtleties.

for a principal

Standardizes which built-ins are safe/portable in CI and documents them for teams.

## Why built-ins exist Maven needs to expose its own build context — coordinates, paths, environment — so you can reference them without hardcoding. These come in named families. ## project.\* Reads the **effective POM** (the merged model after inheritance/defaults). Common ones: - `${project.groupId}`, `${project.artifactId}`, `${project.version}` — the coordinates. - `${project.basedir}` — the module's root directory. - `${project.build.directory}` — usually `target`. - `${project.build.finalName}` — the output artifact base name. Use: stamp `app.version=${project.version}` into a filtered properties file; configure a plugin to write into `${project.build.directory}/reports`. ## settings.\* Reads `~/.m2/settings.xml` (and global settings). Example: - `${settings.localRepository}` — path to the local repository. - `${settings.offline}` — whether Maven is offline. Use: a plugin that needs the local repo path. ## env.\* Maps **OS environment variables**, case can matter by platform: - `${env.HOME}`, `${env.JAVA_HOME}`, `${env.CI}`. Use: detect CI (`${env.CI}`) or reference a tool path provided by the environment. ## System / JVM properties These are JVM-level properties, set by the runtime or via `-Dkey=value`: - `${java.version}` — the running JVM version. - `${user.home}`, `${os.name}`. - Anything you pass: `mvn -Dmy.flag=x ...`. ## A classic gotcha `${java.version}` (a system property) is the **JVM that is running Maven**, which is not necessarily the same as a user-defined `<java.version>` you set under `<properties>` to drive `maven.compiler.release`. Don't conflate them. ## Precedence quick note When the same name could resolve from multiple sources, command-line system properties (`-D`) generally take precedence, then pom `<properties>`, then the built-in families.

  • How can you print the resolved value of a built-in property to verify it?
    Use mvn help:evaluate -Dexpression=project.version -q -DforceStdout.
  • Is ${java.version} the same as a <java.version> you set under <properties>?
    No. The system property ${java.version} is the running JVM version; <java.version> is just a user-defined name you choose, usually to set the compiler release.

saying these in an interview costs you the question

  • Confusing the JVM's ${java.version} system property with a user-defined <java.version>.
  • Assuming env.* names are always case-insensitive across OSes.

context

resolving links…