Why bundle the server with your app

Short answer, to avoid that awkward meeting where someone says the server on prod is different from dev. An executable JAR that contains the Open Liberty runtime gives you a self contained artifact that runs without an external installed server. For Java microservices and DevOps pipelines, that means fewer surprises and faster rollbacks when things go sideways.

Add the Open Liberty runtime and the Maven plugin

Edit pom.xml to include the Open Liberty runtime dependency and the liberty maven plugin so server classes travel with your application code. Also add any feature dependencies your app needs, such as servlet support or JAX RS. The goal is a bootable jar that carries its own embedded server and required features.

What to include in pom.xml

• Add the Open Liberty runtime dependency entry so the runtime jars end up on the classpath.
• Add the liberty maven plugin to the build plugins so Maven can assemble the runnable archive.
• List any Open Liberty features your app uses as dependencies so they start with the embedded server.

Configure the embedded server

Create server.xml fragments for the settings you need, for example feature list, http endpoints and logging. Point the liberty maven plugin at the server.xml you want included and set the packaging goal that produces a runnable archive. This configuration controls which features start and which ports open when the jar runs.

Keep configuration flexible

• Externalize environment specific values so you can swap production and staging without rebuilding.
• Use overlays or environment variables for different profiles in CI and CD.

Build the executable JAR and test locally

Use the normal Maven lifecycle to assemble the jar. A typical command is

mvn clean package

The liberty maven plugin will copy server artifacts and assemble a bootable jar that contains the Open Liberty runtime and your application code. Test the artifact on a developer machine with

java -jar target/myapp.jar

Verify endpoints, health checks and logs. Local testing reduces the risk of surprises during packaging and deployment.

Deploy to WebSphere or an artifact repository

If you deploy to WebSphere use the server deployment tooling or run the jar on infrastructure that supports the Java runtime. Alternatively publish the executable JAR to your artifact repository and let your CI CD pipeline pull it into the target environment. The artifact is portable and fits most deployment workflows.

DevOps tips

• Treat the jar as an immutable artifact and promote the same file from staging to production.
• Keep secrets and large environment specifics out of the jar and load them at runtime.
• Consider containerizing the executable JAR for consistent runtime environments and easier orchestration.

Recap and final wheeze

The process is straightforward and useful. Add Open Liberty dependencies and the liberty maven plugin, configure the embedded server with server.xml fragments, build a runnable jar with mvn clean package, test it locally, and deploy to WebSphere or your artifact repo. You end up with an executable JAR that makes deployment simpler and less likely to surprise anyone who likes being blamed for outages.