skip to content

WAR, EAR & Executables

2 roadmaps5 questions

Packaging web and enterprise archives, plus executable or layered Spring Boot jars and jlink/jpackage distributions. Interviewers use it to place your experience: servlet containers, fat jars, or self-contained runtimes.

on this pageshow

explore

questions

5

What does the <packaging> element control in a Maven POM, and what is the difference between jar, war, and ear packaging?

level: juniorimportance: must knowfreq 70%

answer

  1. packaging selects artifact + lifecycle
  2. war = WEB-INF/lib + classes
  3. ear = multi-module + application.xml
  4. pom = no artifact

basics

~20 s

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

solid answer

~40 s

The <packaging> element selects the artifact type and binds a default set of plugin goals to the build lifecycle. jar (the default) produces an ordinary archive of compiled classes and resources. war produces a Web Application Archive with a WEB-INF/classes folder, WEB-INF/lib for dependency jars, and web resources at the root — deployed to a servlet container like Tomcat via the maven-war-plugin. ear produces an Enterprise Application Archive grouping several modules (wars, ejb-jars, libraries) plus an application.xml, built by the maven-ear-plugin and deployed to a full Java EE/Jakarta EE server. There is also pom packaging for aggregator/parent projects that build no artifact. Each packaging changes which lifecycle bindings run, so choosing war versus jar fundamentally changes what mvn package emits.

code

xml · 2 lines
xml
<packaging>war</packaging>
<!-- emits target/shop-web-1.0.0.war with WEB-INF/classes, WEB-INF/lib -->

go deeper

for a junior

Know the three names and that war is for web apps, jar is the default.

for a middle

Explain the WEB-INF layout and that packaging changes lifecycle bindings.

for a senior

Discuss provided scope, ear-vs-war target runtimes, and when to choose each.

for a principal

Set org-wide conventions: executable jars for cloud vs war/ear for legacy app servers, and standardize packaging across the module graph.

## What <packaging> is Every Maven project declares a `<packaging>` in its `pom.xml` (Project Object Model — the XML file describing the build). It defaults to `jar`. This single element does two things: it decides the **type of artifact** produced by `mvn package`, and it selects a **lifecycle mapping** — the set of plugin goals automatically bound to each build phase (`compile`, `test`, `package`, etc.). ## The common packaging types - **jar** — a Java ARchive, a zip of `.class` files and resources. The default. Built by `maven-jar-plugin`. - **war** — a Web Application aRchive. Built by `maven-war-plugin`. Its layout is fixed: compiled classes go to `WEB-INF/classes`, runtime dependency jars go to `WEB-INF/lib`, and static web content (HTML, JSP) sits at the archive root. A war is deployed into a **servlet container** (Tomcat, Jetty). - **ear** — an Enterprise ARchive. Built by `maven-ear-plugin`. It aggregates **multiple modules** — wars, EJB jars, and shared libraries — and carries an `application.xml` deployment descriptor. An ear targets a **full Jakarta/Java EE application server** (WildFly, WebLogic), not a plain servlet container. - **pom** — no binary artifact; used by parent/aggregator projects that only build child modules. ## Why it matters Because packaging swaps the lifecycle bindings, the same `mvn package` command does very different work. For a war, dependencies are folded into the archive; for a jar, they are not. Picking the wrong packaging produces an artifact your runtime cannot deploy. ```xml <project> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>shop-web</artifactId> <version>1.0.0</version> <packaging>war</packaging> </project> ``` Modern cloud deployment increasingly favors an **executable jar** (a war/jar that embeds its own server) over the war-into-container model, but war and ear remain common in enterprise and app-server environments.

  • Where do a war's dependency jars end up?
    Runtime/compile-scoped dependencies are copied into WEB-INF/lib inside the archive; provided-scoped ones (like the servlet API) are excluded because the container supplies them.
  • What packaging does a parent/aggregator project use?
    pom packaging — it produces no binary artifact and just coordinates its child modules.

saying these in an interview costs you the question

  • Saying war and jar are interchangeable
  • Claiming the servlet-api jar is bundled into a war (it is provided by the container)
  • Thinking ear is just a renamed war rather than a multi-module container

context

resolving links…

open as a page

What does the spring-boot-maven-plugin's repackage goal do, and what is a layered jar?

level: middleimportance: must knowfreq 65%

basics

~20 s

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.

open as a page

How does the maven-war-plugin assemble a war, and how do dependency scopes affect what ends up inside it?

level: middleimportance: should knowfreq 50%

basics

~10 s

The war plugin copies your classes to WEB-INF/classes and your compile/runtime dependencies to WEB-INF/lib, plus web resources at the root. provided and test scoped dependencies are left out so the container supplies them.

open as a page

Compare the ways to produce a runnable Java distribution with Maven: shade/assembly uber-jars, Spring Boot repackage, and OS-native distributions via appassembler, jlink, or jpackage. When would you pick each?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Uber-jars (shade/assembly) and Spring Boot repackage bundle everything into one runnable jar needing only a JRE. appassembler generates start scripts plus a lib folder. jlink builds a trimmed custom runtime image, and jpackage produces a native OS installer or app bundle that includes a runtime, so users need no separate Java install.

open as a page

What is the maven-ear-plugin used for, how is an EAR project structured, and why has it largely fallen out of favor?

level: seniorimportance: nice to knowfreq 20%

basics

~20 s

maven-ear-plugin builds an EAR — an enterprise archive that groups several modules (wars, EJB jars, libraries) and generates application.xml for deployment to a full Jakarta EE application server. It's faded because Spring Boot executable jars and microservices replaced the monolithic app-server model.

open as a page