skip to content

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%

answer

  1. EAR = multi-module enterprise archive
  2. ear-plugin generates application.xml + contextRoot
  3. reactor: ejb + war + ear
  4. needs full app server (WildFly/WebLogic)
  5. declined: Boot fat jars + microservices

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.

solid answer

~50 s

The maven-ear-plugin assembles an Enterprise Archive for a pom-less aggregation model: a parent ear module declares the other modules (war, ejb, jar) as dependencies with <modules> configuration, and the plugin lays them at the EAR root and generates (or includes) application.xml — the Jakarta EE deployment descriptor listing each module and context root. The EAR deploys to a full application server (WildFly, WebLogic, GlassFish) that provides the EE container, shared class loading, and JNDI. You typically have a reactor: an ejb module, a war module, and an ear module that bundles them. It has declined because the heavyweight app-server + EAR model lost ground to Spring Boot fat jars, embedded servers, and microservices, where each service is a self-contained executable artifact rather than co-deployed modules in one container. EARs persist mainly in legacy enterprise estates.

code

xml · 15 lines
xml
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-ear-plugin</artifactId>
  <configuration>
    <version>9</version>
    <defaultLibBundleDir>lib</defaultLibBundleDir>
    <modules>
      <webModule>
        <groupId>com.example</groupId>
        <artifactId>shop-web</artifactId>
        <contextRoot>/shop</contextRoot>
      </webModule>
    </modules>
  </configuration>
</plugin>

go deeper

for a junior

Know an EAR bundles multiple modules for a Java EE app server.

for a middle

Describe the ejb+war+ear reactor and that the plugin generates application.xml.

for a senior

Explain contextRoot/lib configuration and why microservices/Boot displaced EARs.

for a principal

Advise legacy-modernization: when to keep EAR/app-server vs decompose into executable services, weighing EJB/JTA coupling.

## What an EAR is An **EAR** (Enterprise ARchive) is a Jakarta/Java EE packaging that groups **multiple deployable modules** into one unit deployed to a **full application server** (the EE container that supplies EJB, JTA transactions, JNDI, connection pooling, shared classloading). The **`maven-ear-plugin`** builds it. ## Project structure (a Maven reactor) A typical EAR build is a multi-module reactor: ``` shop-parent (pom) ├── shop-ejb (ejb) -> business logic / EJBs ├── shop-web (war) -> the web tier └── shop-ear (ear) -> bundles ejb + war + shared libs ``` The `ear` module lists the others as dependencies and configures the plugin's `<modules>`: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <version>3.3.0</version> <configuration> <version>9</version> <!-- Jakarta EE 9 application.xml --> <modules> <webModule> <groupId>com.example</groupId> <artifactId>shop-web</artifactId> <contextRoot>/shop</contextRoot> </webModule> <ejbModule> <groupId>com.example</groupId> <artifactId>shop-ejb</artifactId> </ejbModule> </modules> </configuration> </plugin> ``` ## What the plugin emits - The wars/ejb-jars at the EAR root. - A `lib/` folder for shared libraries (controlled by `<defaultLibBundleDir>`). - `META-INF/application.xml` — the deployment descriptor enumerating modules and context roots. The plugin can **generate** it (driven by `<version>` and `<modules>`) or use a hand-written one. ## Why it has declined - **Operational weight:** a full app server is heavy to run, patch, and tune versus an embedded server. - **Microservices & cloud:** the industry moved to one **self-contained executable artifact per service** (Spring Boot fat jar, layered jar, container image) instead of co-deploying modules in a shared container. - **Classloading complexity:** EAR-level shared vs module-level classloading is a frequent source of `ClassCastException`/visibility bugs. EARs remain in **legacy enterprise** environments (WebLogic, WebSphere, WildFly) and where EJB/JTA features are deeply relied upon, but greenfield work rarely chooses them.

  • What does application.xml contain in an EAR?
    The Jakarta EE deployment descriptor listing each bundled module (web/ejb/connector), the web module's context-root, and shared library locations the application server uses to deploy the EAR.
  • What replaced the EAR + app-server model in modern Java?
    Self-contained executable jars with embedded servers (e.g., Spring Boot repackage / layered jars) and per-service container images in a microservice architecture.

saying these in an interview costs you the question

  • Saying an EAR deploys to a plain servlet container like Tomcat (it needs a full EE app server)
  • Confusing EAR (multi-module) with a single war
  • Claiming EARs are the modern default for new Java apps

context

resolving links…