skip to content

When the assembly plugin runs, what artifact does it produce relative to the main jar, and how does it get installed and deployed?

level: seniorimportance: nice to knowfreq 22%

answer

  1. attached secondary artifact
  2. classifier = assembly <id>
  3. install/deploy carry it along
  4. attach=false to skip repo
  5. appendAssemblyId=false drops classifier

basics

~20 s

By default the assembly is attached as a secondary artifact with a classifier (the assembly id, e.g. -dist), alongside the main jar. Because it's attached, mvn install and deploy will install/upload it to the repository too.

solid answer

~40 s

The `single` goal, by default, **attaches** the assembled archive to the project as an additional artifact identified by a **classifier** equal to the assembly `<id>` (so `app-1.0-dist.tar.gz` shares the GAV but has classifier `dist`). Being attached means it participates in the lifecycle: `mvn install` copies it to the local repo and `mvn deploy` uploads it to the remote repository next to the main jar and pom. You can turn this off with `<attach>false</attach>` if it's purely a local deliverable. With `<appendAssemblyId>false</appendAssemblyId>` the classifier/suffix is dropped, which for a fat jar can make it *replace* the main artifact name — do that deliberately. Multiple executions with different ids produce multiple attached classifiers (e.g. one zip, one tar.gz).

code

bash · 3 lines
bash
mvn clean deploy
# uploads: app-1.0.jar (main), app-1.0.pom,
#          app-1.0-dist.tar.gz (classifier=dist, attached)

go deeper

for a junior

Knows the assembly file appears in target/ after package.

for a middle

Knows it gets a classifier and is installed locally.

for a senior

Understands attach semantics, deploy behavior, and classifier collisions.

for a principal

Designs release pipelines so distributions are versioned/published consistently across the org.

## Main artifact vs attached artifact Every Maven module has one **main artifact** (for `jar` packaging, the plain jar). The assembly plugin doesn't replace it — by default it adds a **secondary (attached) artifact** that shares the project's groupId/artifactId/version but is distinguished by a **classifier**. The classifier defaults to the assembly's **`<id>`**. So an assembly with `<id>jar-with-dependencies</id>` yields `app-1.0-jar-with-dependencies.jar`, and one with `<id>dist</id>` yields `app-1.0-dist.tar.gz`. ## Why 'attached' matters Attached artifacts are first-class lifecycle citizens: - `mvn install` installs the main jar **and** every attached assembly into `~/.m2/repository`. - `mvn deploy` uploads all of them to the remote repository (Nexus/Artifactory) alongside the pom. That's exactly what you want for a downloadable distribution: consumers can pull `groupId:artifactId:version:[email protected]`. ## Controlling attachment ```xml <configuration> <attach>false</attach> <!-- don't install/deploy it --> <appendAssemblyId>false</appendAssemblyId> <!-- drop the classifier/suffix --> </configuration> ``` - `<attach>false</attach>` — build the file in `target/` but keep it out of the repository (useful for ephemeral local bundles). - `<appendAssemblyId>false</appendAssemblyId>` — removes the id suffix from the filename. For a single fat jar people use this to ship a clean `app-1.0.jar`. Caution: without a classifier two artifacts of the same type can collide; this is fine for a fat jar that's meant to *be* the deliverable but can confuse install if the main jar has the same name/type. ## Multiple assemblies Define several `<execution>`s (or several `<descriptorRefs>`/`<descriptors>`), each with a distinct id, to attach multiple classifiers — e.g. a `-bin` tar.gz for ops and a `-src` zip for source distribution. ## CLI ```bash mvn clean install # builds + attaches assembly into local repo mvn deploy # uploads main jar + attached assemblies + pom ```

  • How does a consumer declare a dependency on the assembled tar.gz?
    By coordinate with classifier and type, e.g. <classifier>dist</classifier><type>tar.gz</type> on the dependency element.
  • You don't want the dev fat jar uploaded to your shared repo. What do you set?
    <attach>false</attach> on the assembly configuration so it's built in target/ but never installed or deployed.

saying these in an interview costs you the question

  • Thinking the assembly replaces the main jar by default — it's attached with a classifier.
  • Assuming attached assemblies are not deployed — mvn deploy uploads them too unless attach=false.
  • Setting appendAssemblyId=false blindly and causing artifact name collisions.

context

resolving links…