Packaging, delivery and operational acceptance

From source archive to executable

The Boot Maven plugin uses repackage on the JAR or WAR produced by the package phase. The result includes the layout and dependencies needed by the configured execution form. The goal should not be interpreted as a replacement for the phase producing the source archive.

With starter-parent, the repackage execution is already prepared and declaring the plugin participates in that pattern. Without the parent, configure the execution explicitly. The original archive normally receives the .original suffix; the pipeline must select the correct output instead of choosing any file with the same version.

Read layout and manifest

In a repackaged JAR, application classes and libraries normally occupy BOOT-INF/classes and BOOT-INF/lib. The Boot plugin manages manifest entries such as Main-Class and Start-Class. Changing only an extension or a jar-plugin entry does not reproduce that entire contract.

When a candidate fails to start, first compare selected artifact type, layout and main class with the packaging model. Increasing memory does not convert .original into the expected executable. Diagnosis should preserve the exact identity of bytes producing the failure.

Declared identity and content

build-info generates META-INF/build-info.properties with coordinates and build information that Actuator can display. This metadata helps answer which version an instance declares. It is not a cryptographic signature, integrity proof or production approval.

Two builds can declare the same version while having different content. If policy requires promoting exactly the reviewed candidate, retain a content identifier and its link to acceptance evidence. Copying metadata from an approved candidate to another does not transfer the validity of that review.

Layers by change frequency

The layer index distinguishes stable dependencies, loader, snapshot dependencies and application. Separation lets tools reuse unchanged layers when only application code changes. The benefit depends on the build process using that organization.

A layered image still needs compatible dependencies, controlled identity and appropriate configuration. Reusing a layer does not establish that libraries are current or the service ready for traffic. The index organizes content; it does not replace the acceptance decision.

Reconcile shutdown deadlines

Graceful shutdown occurs during context closing and gives existing requests a bounded period while stopping new requests according to server behavior. spring.lifecycle.timeout-per-shutdown-phase configures the per-phase timeout. It does not automatically extend a deadline imposed by an external supervisor.

If the application requests 20 seconds and the platform kills the process at 10, a 15-second request can lose its response. Traffic removal, shutdown phases and external termination need a coherent budget. Abrupt termination can prevent the graceful path.

Uncertain outcome after interruption

Losing a response does not prove that an operation had no effects. A write can commit before the connection is interrupted. A retry decision needs operation identity, outcome observation and a policy avoiding duplication when the business requires that property.

Graceful shutdown reduces interruptions within its conditions but offers neither universal rollback nor unlimited completion. In this lesson’s scenario, the next step is reconciling persisted effects and actual deadlines. Restarting the process does not automatically erase committed reservations, messages or remote actions.

Accept and recover with real dependencies

A promotion decision should link candidate content to behavioral checks and feasible recovery. Health UP and the expected version are useful signals but do not automatically cover authorization, HTTP contracts, data, long-running operations or external consumers. State the limits of each piece of evidence.

If a migration removes a column required by the previous version, returning to the old JAR can fail. Recovery must consider data state and coexisting versions. In the exercise, select decisions supported by the supplied records; build, container or migration execution is not required.

Common pitfalls

Publishing .original by mistake; treating build-info as a signature; assuming layers guarantee security; setting a shutdown timeout longer than the platform deadline; returning to the old binary without checking data compatibility.