Maven

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.

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.

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.

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.

<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.

A phase (e.g. package) runs every step bound to it and all earlier phases in order. A goal (e.g. compiler:compile) runs just that one plugin task by itself.

A lifecycle phase (like compile) is just a named step that does nothing by itself. Plugin goals are 'bound' to phases, so running 'mvn compile' actually runs the goals attached to that phase, like compiler:compile.

The main default phases run in order: validate, compile, test, package, verify, install, deploy. Validate checks the project, compile builds source, test runs unit tests, package makes the jar/war, verify runs checks, install copies to the local repo, deploy uploads to a remote repo.

Maven has three built-in lifecycles: clean (deletes previous build output), default (builds, tests, packages and deploys the project), and site (generates project documentation/reports).

-DskipTests compiles tests but skips running them. -Dmaven.test.skip=true skips both compiling AND running tests. -D sets a system/user property that plugins and the POM can read.

Run mvn dependency:tree. It prints every dependency your project pulls in, including transitive ones, as an indented tree showing which dependency brought in which, plus the scope and version of each.

Maven has six scopes: compile (default, everywhere), provided (compile/test only, supplied at runtime by the container), runtime (not for compiling, needed to run), test (only for tests), system (like provided but you give a local jar path), and import (only for BOMs in dependencyManagement).

Transitive dependencies are the dependencies of your dependencies. If you declare library A and A needs B, Maven automatically downloads B too, so you don't have to list it yourself.

<dependencyManagement> declares versions (and other settings) centrally but does NOT add the dependency to the build. Child modules that list the same dependency without a version inherit the managed version. Plain <dependencies> actually pulls the jar onto the classpath.

provided is on the compile and test classpaths but NOT packaged or shipped, because something else (a container/JDK) supplies it at runtime. runtime is the opposite: NOT on the compile classpath but available (and packaged) for running and testing.

The compiler plugin's compiler:compile goal binds to the compile phase (main sources) and compiler:testCompile binds to test-compile (test sources). Maven binds these automatically for jar projects.

The <configuration> block sets a plugin's parameters in the pom.xml. Each child element name matches a plugin parameter (for example <source>17</source> for the compiler), and Maven injects those values into the plugin Mojo when it runs.

Core build plugins handle the standard build steps: clean removes target/, resources copies non-code files, jar packages a JAR, install copies the artifact to the local repository, and deploy uploads it to a remote repository.

A Maven plugin is a bundle of related tasks. Each task is a 'goal', implemented by a class called a mojo. You run a goal like mvn compiler:compile, where compiler is the plugin and compile is the goal.

A Mojo is the Java class behind one Maven goal. You extend AbstractMojo, annotate the class with @Mojo(name = "..."), implement execute(), and package it as a maven-plugin artifact so Maven can run it.

A Maven profile is a named set of build settings (dependencies, plugins, properties) that can be turned on or off. You use it to vary the build for different environments like dev, test, and prod without changing the main configuration.

Credentials go in ~/.m2/settings.xml inside a <server> entry (id, username, password). Maven can encrypt the password so settings.xml holds an {encrypted} value instead of the real one, decrypted at build time using a master password.

Maven reads two settings.xml files: a global one in the Maven install directory (${maven.home}/conf) and a user one in ~/.m2. The user file overrides the global file. Settings hold machine-level config like credentials and mirrors, not project info.

Besides activating with -P, a profile's <activation> can turn it on automatically: activeByDefault, a property being set, a JDK version range, the OS, or whether a file exists or is missing.

First run mvn --encrypt-master-password to create the master, paste its output into ~/.m2/settings-security.xml. Then run mvn --encrypt-password for each server password and paste the {token} into the <server><password> in settings.xml.

Add the jacoco-maven-plugin and bind its prepare-agent goal. prepare-agent sets a property (argLine) that adds the JaCoCo Java agent to the JVM running your tests, so it records which lines execute.

Use the requireMavenVersion and requireJavaVersion rules with a version range. For example [3.9,) means '3.9 or higher'. The build fails if the running Maven or JDK is outside the range.

The Enforcer Plugin lets you declare build rules (like a minimum Maven or Java version) and fails the build automatically when they are violated, so problems are caught early instead of at runtime.

Failsafe runs integration tests; Surefire runs unit tests. Surefire fails the build immediately on a test failure, while Failsafe defers failure so teardown always runs.

Static analysis plugins inspect source/bytecode for style and bug issues without running it. You add the plugin to your pom and bind its check goal to a build phase (often verify) inside an <execution> so mvn verify runs it automatically.

<packaging> tells Maven what artifact to build and which lifecycle to use. jar makes a plain Java archive, war makes a web app archive for a servlet container, and ear bundles multiple modules for a Java EE app server.

The assembly plugin bundles your project output plus extra files (dependencies, scripts, docs) into a single distributable archive like a zip, tar.gz, or a fat jar. The default jar packaging only packs your own compiled classes.

MANIFEST.MF lives in META-INF/ inside a JAR and holds metadata as key: value lines (like the entry-point class). The maven-jar-plugin generates it automatically when you build with packaging jar.

An uber-JAR is a single JAR that bundles your code plus all dependency classes, so it runs standalone with java -jar. maven-shade-plugin unpacks every dependency JAR and merges the classes into one output JAR.

The repackage goal takes the plain jar Maven built and rewrites it into an executable fat jar that embeds all dependencies and a launcher, so you can run it with java -jar. A layered jar splits it into layers ordered by change frequency to make Docker image builds cache better.

Because it isn't a real artifact like a jar — it only organizes other modules and/or shares config. packaging=pom makes Maven install just the POM file itself (no jar/war), and it is required for any POM with a <modules> section.

The reactor is Maven's engine that figures out which modules to build and in what order based on dependencies. To build one module, run from the root: mvn install -pl :artifactId (or -pl module-path).

Maven's reactor builds modules in dependency order, not in the order they are listed in <modules>. It looks at each module's <dependency> entries and builds a needed module before the one that depends on it.

Aggregation means a parent POM lists child <modules> so one build command builds them all. Inheritance means a child declares a <parent> and reuses its config (versions, plugins, dependencies). They are independent concerns that often live in the same POM.

Put a <dependencyManagement> block (and version properties) in the shared parent POM. Child modules declare dependencies without versions, so every module uses the parent's pinned version.

A mirror in settings.xml redirects requests for one or more repositories to a different URL. Teams use it to point all downloads at an internal repository manager instead of public servers.

A SNAPSHOT (e.g. 1.0.0-SNAPSHOT) is a mutable in-development version that can change at any time; a release (e.g. 1.0.0) is immutable and published once. Releasing means dropping -SNAPSHOT and locking the artifact.

The local repository is a folder on your machine (by default ~/.m2/repository) where Maven caches every downloaded dependency and plugin, plus artifacts you build and install yourself, so it doesn't re-download them.

deploy is the last phase of the default lifecycle. The maven-deploy-plugin's deploy goal uploads the built artifact, its POM, and metadata to the remote repository. install (earlier) only copies it to your local ~/.m2 repo.

A SNAPSHOT (e.g. 1.0.0-SNAPSHOT) is an in-development, mutable version Maven re-checks and may re-download; a release (e.g. 1.0.0) is final and immutable, downloaded once and cached forever.

An archetype is a project template. You run mvn archetype:generate, pick a template, and answer prompts for groupId, artifactId and version; Maven creates a ready-to-build project skeleton from that template.

The Maven Wrapper is a small script (mvnw on Unix, mvnw.cmd on Windows) checked into the repo. Running ./mvnw downloads and uses a fixed Maven version automatically, so everyone builds with the same Maven without installing it.

Use the -T flag, e.g. mvn -T 4 install for 4 threads or mvn -T 1C install for one thread per CPU core. Maven builds independent modules of the reactor concurrently.

distributionUrl is the URL of the exact Maven version zip the wrapper downloads and runs. wrapperUrl is where the wrapper's own bootstrap jar is fetched from. Changing distributionUrl pins a different Maven version.

It's a utility plugin that adds small 'glue' goals Maven core lacks: registering extra source/test folders, attaching extra build outputs as artifacts, parsing versions, extracting a property by regex, and reserving free network ports.

An SBOM (Software Bill of Materials) is a machine-readable inventory of every dependency in your build. In Maven you generate one with the cyclonedx-maven-plugin, usually its makeBom goal, which writes bom.xml/bom.json.

It is a Maven plugin that scans your project's dependencies for known security vulnerabilities (CVEs) by matching them against a public vulnerability database, and can fail the build if it finds risky libraries.

An attacker publishes a package to a public repo with the same groupId/artifactId as your internal one. If your build can reach both repos, it may download the malicious public version instead of the private one.

makeBom produces one SBOM per module from that module's dependencies. makeAggregateBom runs once for a multi-module (reactor) build and produces a single SBOM covering all modules together.

Add a <mirror> in settings.xml with <mirrorOf>*</mirrorOf> pointing at your trusted virtual repo. That redirects every repository request through it, so builds never hit untrusted public repos directly.