skip to content

Project Object Model

4 roadmaps21 questions

The pom.xml itself — coordinates, dependencies, plugins, inheritance, properties — and how all of it collapses into one effective POM. Interviewers use the POM to check whether you can read a build file rather than only paste snippets into it.

on this pageshow

explore

questions

21

What are Maven coordinates (GAV), and what does each part identify?

level: juniorimportance: must knowfreq 80%

answer

  1. groupId = reverse-DNS namespace
  2. artifactId = project name
  3. version = release id
  4. GAV → repo path
  5. packaging + classifier optional

basics

~10 s

GAV stands for groupId, artifactId, version. Together they uniquely identify an artifact in a Maven repository. groupId is the owning org/namespace, artifactId is the project name, version is the release.

solid answer

~40 s

Maven coordinates uniquely address an artifact. The core triple is groupId (a reverse-DNS namespace for the owning org/team, e.g. org.springframework), artifactId (the specific module name, e.g. spring-core), and version (e.g. 5.3.30). Together GAV forms the address Maven uses to store, resolve, and download the artifact from a repository, mapping to a path like org/springframework/spring-core/5.3.30/. Two optional coordinates extend this: packaging (defaults to jar, decides the build lifecycle and output type) and classifier (a suffix to ship secondary artifacts like sources or javadoc alongside the main one). When you declare a dependency you give at least GAV; Maven uses it both to find your project's own output and to locate dependencies transitively.

code

xml · 5 lines
xml
<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang3</artifactId>
  <version>3.14.0</version>
</dependency>

go deeper

for a junior

Recall that GAV = groupId, artifactId, version and that it uniquely identifies an artifact.

for a middle

Explain how GAV maps to the repository path and filename, plus the optional packaging/classifier coordinates.

for a senior

Discuss naming conventions, namespace ownership, and how GAV drives transitive resolution and conflict mediation.

for a principal

Govern org-wide groupId conventions, artifact naming standards, and how coordinate hygiene affects monorepo/multi-team artifact discoverability.

## What are Maven coordinates? Maven is a build tool that stores every built artifact (a JAR, WAR, etc.) in a **repository** — a structured directory tree (your local `~/.m2/repository`, plus remote ones like Maven Central). To find any artifact unambiguously, Maven gives each one an address called its **coordinates**, commonly abbreviated **GAV**. ## The three core coordinates - **groupId** — a namespace identifying the organization or team that owns the artifact. By convention it uses reverse-DNS, e.g. `org.apache.commons`. This avoids name clashes between different vendors. - **artifactId** — the name of the specific project/module within that group, e.g. `commons-lang3`. Must be unique within the group. - **version** — the release identity, e.g. `3.14.0`. Distinguishes builds of the same project over time. ## How coordinates map to a path Maven turns GAV into a repository path by replacing dots in groupId with slashes: ``` org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar ``` The filename is `<artifactId>-<version>[-<classifier>].<extension>`. ## Two optional coordinates - **packaging** (`<packaging>`) — defaults to `jar`. It selects the build lifecycle bindings and the output type (jar, war, pom, etc.). - **classifier** (`<classifier>`) — an optional suffix that lets one GAV ship multiple artifacts, e.g. `sources`, `javadoc`, or a platform-specific build. ## In a pom.xml ```xml <project> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>billing-service</artifactId> <version>1.4.2</version> <packaging>jar</packaging> </project> ``` The same triple appears when you depend on something: ```xml <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.14.0</version> </dependency> ``` Maven uses GAV both to publish your project's output and to resolve every dependency (and their transitive dependencies) from repositories.

  • Why is reverse-DNS used for groupId?
    To guarantee global uniqueness across vendors — you own example.com, so com.example won't clash with anyone else's namespace.
  • What is the minimum needed to declare a dependency?
    groupId, artifactId, and a version (the version can be omitted if managed via dependencyManagement or a BOM).

GAV is like a postal address: groupId is the city/zone, artifactId is the street, version is the house number — together they point to exactly one place.

saying these in an interview costs you the question

  • Saying groupId and artifactId are interchangeable
  • Claiming version is optional in all cases (it's required unless managed)
  • Thinking coordinates are just labels and not the actual lookup key in the repository

context

resolving links…

open as a page

What is the 'effective POM' in Maven, and how does it differ from the pom.xml you write by hand?

level: juniorimportance: must knowfreq 70%

basics

~10 s

The effective POM is the final, fully-merged project model Maven actually builds with. It combines your pom.xml with the built-in Super POM, parent POMs, and active profiles, filling in all defaults.

open as a page

What is POM inheritance in Maven, and how does a child POM declare its parent?

level: juniorimportance: must knowfreq 70%

basics

~10 s

A child POM points at a parent POM via the <parent> element (groupId, artifactId, version). The child then automatically gets the parent's configuration unless it overrides it.

open as a page

What are Maven properties, and how do you define and reference a custom property in a pom.xml?

level: juniorimportance: must knowfreq 70%

basics

~10 s

Properties are named placeholders you set under <properties> in the pom and reference with ${name}. They let you avoid repeating values like version numbers in one central place.

open as a page

What does the <packaging> element do, and what are the common packaging types?

level: middleimportance: must knowfreq 70%

basics

~10 s

<packaging> tells Maven what kind of artifact to build and which lifecycle bindings to use. Common values: jar (default), war (web app), pom (aggregator/parent), and maven-plugin.

open as a page

What is Maven resource filtering, and how do you turn it on so ${} placeholders in your resource files get replaced at build time?

level: middleimportance: must knowfreq 60%

basics

~10 s

Resource filtering is when the maven-resources-plugin copies files from src/main/resources to target and replaces ${...} tokens inside them with property values. You enable it by setting <filtering>true</filtering> on a <resource>.

open as a page

Explain SNAPSHOT versus release versions in Maven, including deploy and timestamping semantics.

level: seniorimportance: must knowfreq 75%

basics

~20 s

A version ending in -SNAPSHOT is a mutable in-development version Maven re-checks for updates. A release version (no -SNAPSHOT) is immutable — once deployed it should never change. On deploy, snapshots get timestamped unique filenames; releases keep their plain version.

open as a page

How do active profiles affect the effective POM, and how do you tell which profiles are active?

level: seniorimportance: must knowfreq 50%

basics

~20 s

Active profiles inject extra dependencies, plugins, properties, or repositories into the computed model, merged on top after inheritance. Profiles can be activated by -P, settings.xml, activeByDefault, OS, JDK, property, or file. Check with mvn help:active-profiles or help:effective-pom.

open as a page

What is the difference between inheriting <dependencyManagement> and inheriting <dependencies> from a parent POM?

level: seniorimportance: must knowfreq 65%

basics

~10 s

<dependencies> in the parent are actually added to every child. <dependencyManagement> only sets default versions/scopes; a child still has to declare the dependency (without a version) to use it.

open as a page

Explain the difference between inheritance and aggregation (the <modules> reactor) in Maven multi-module builds.

level: seniorimportance: must knowfreq 60%

basics

~10 s

Inheritance (<parent>) shares configuration with children. Aggregation (<modules> in a pom-packaging project) groups submodules so one mvn command builds them all in dependency order. They are independent and often combined.

open as a page

What is <finalName> in the build section, and how does it relate to coordinates and the deployed artifact name?

level: middleimportance: should knowfreq 35%

basics

~10 s

<finalName> sets the base name of the output file produced in the target/ directory (e.g. target/app.war instead of app-1.0.0.war). It defaults to artifactId-version. It only renames the local build output, not the repository coordinates.

open as a page

What is the role of <modelVersion>4.0.0</modelVersion> and the Super POM in how a project model is resolved?

level: middleimportance: should knowfreq 45%

basics

~10 s

<modelVersion>4.0.0</modelVersion> declares which POM schema your file uses; it's mandatory. The Super POM is Maven's built-in implicit parent that supplies default repositories, directories, and plugin bindings every project inherits.

open as a page

How are <properties> and plugin configuration merged across the inheritance chain, and how does a child override them?

level: middleimportance: should knowfreq 45%

basics

~10 s

Properties and config are merged from the Super POM down through parents to the child. Anything the child redefines wins. So the child's value overrides the parent's, which overrides the Super POM's.

open as a page

What does <relativePath> do in a <parent> declaration, and how does Maven resolve the parent POM?

level: middleimportance: should knowfreq 50%

basics

~10 s

<relativePath> tells Maven where on disk to find the parent POM. By default it is ../pom.xml. If the parent isn't there, Maven downloads it from a repository instead.

open as a page

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%

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.

open as a page

What is a <classifier> in Maven and when would you use one?

level: seniorimportance: should knowfreq 45%

basics

~20 s

A classifier is an optional extra coordinate appended to the artifact filename, letting one GAV publish several distinct artifacts — for example -sources, -javadoc, or platform-specific builds — that share the same groupId, artifactId, and version.

open as a page

A teammate's build pulls a dependency version nobody declared, and a plugin runs with unexpected config. How do you diagnose this using the effective POM and related tools?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Generate the effective POM with mvn help:effective-pom to see the fully merged, resolved model and find where the version/config came from. For transitive dependency versions, also use mvn dependency:tree. Check active profiles and settings too.

open as a page

How does Maven merge inherited and management sections into the effective model? Give the precedence rules for inheritance vs. override.

level: seniorimportance: should knowfreq 40%

basics

~20 s

Maven merges from the Super POM up through parents to the child, with child values overriding parent values. Lists (dependencies, plugins) accumulate; scalar values are replaced. Management sections supply defaults the child can use without re-specifying versions.

open as a page

How do <build><filters> files relate to resource filtering, and when would you use them instead of <properties>?

level: seniorimportance: should knowfreq 35%

basics

~10 s

<filters> points to external .properties files whose key=value pairs become available during resource filtering, alongside pom properties. You use them to keep environment-specific values out of the pom, often selected per Maven profile.

open as a page

What pitfalls and precedence rules govern ${} interpolation across the pom, resources, and the command line — and how would you debug an unresolved or wrong value?

level: seniorimportance: should knowfreq 30%

basics

~20 s

Interpolation replaces ${name} from sources with a precedence order (roughly -D system props > pom properties > built-ins). Pitfalls: unfiltered resources keep tokens literally, ${} clashes with framework placeholders, and unknown tokens stay as-is. Debug with mvn help:evaluate and effective-pom.

open as a page

How does Maven parse and order version strings, and why does that matter for ranges and conflict resolution?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

Maven splits versions into numeric and qualifier tokens separated by dots/dashes and compares them token by token. Known qualifiers like alpha < beta < milestone < rc < snapshot < (release) < sp order specially; unknown qualifiers sort alphabetically after the release.

open as a page