Spring Boot applications are primarily distributed as a standard Java application packed inside a JAR. The JAR of any Spring Boot application contains all the dependencies required for Spring Framework applications to be run. To build a Spring Boot application, Maven can be utilized. The Spring Boot Maven plugin, which has been present in Maven's pom.xml file since the development phase, automatically hooks onto the build process and creates a directly executable Spring Boot JAR.

The whole process is triggered by instructing Maven to package the application. Executing the maven package command should be either done on the {project-root} folder, or by pointing Maven to {project-root} using the mvn package -f path/to/pom.xml parameter. {project-root} stands for the folder where the pom.xml of the Spring Boot Weather Microservice resides:

> mvn package
...several output omitted...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

After Maven is instructed to package the application, a new folder appears in {project-root}. In this folder, the Spring Boot Microservice build can be found:

.{project-root}
├── pom.xml
├── src
├── target

Inside the target/ folder, several sub-folders and files emerge. Most of the folders are a standard output of the Java application-compilation and -assembly process, such as generated sources or Javadoc documentation. The structure of the target/ folder is demonstrated here:

. {project-root/target}
├── classes
├── generated-sources
├── maven-archiver
├── maven-status
├── weather-service-spring-1.0-SNAPSHOT.jar
└── weather-service-spring-1.0-SNAPSHOT.jar.original

Two files are of particular interest regarding Spring Boot: there are two JAR to be found. Those JARs almost have the same name, but one of them is suffixed with the .original string:

• weather-service-spring-1.0-SNAPSHOT.jar
• weather-service-spring-1.0-SNAPSHOT.jar.original

The suffixed original JAR is built first. This JAR is the output of the standard Maven build pipeline when the MVN package command is invoked. This archive is only a few kilobytes in size, containing nothing but the business logic of the application. There is no Spring Framework library included. This archive is taken by the Spring Boot Maven plugin and transformed into a new JAR, called Fat JAR. The old one is then kept aside at the same location with the afore-mentioned .original suffix.

A Fat JAR is a common name for a Java application packed in a single JAR with all the dependencies required. The process of transforming a simple Java Archive into a Spring Boot Fat JAR includes importing the required libraries into the newly-created JAR. Everything from Spring Framework libraries to the Java EE specification implementations that Spring Framework depends on is included. With Spring Boot, the Spring Framework core principles remain. Years ago, Spring Framework applications were dependent on several Java EE specifications, most noticeably on the servlet specification. As a result, Spring Framework was commonly deployed to an Application Server or a Servlet Container. This dependency on Java EE remains. However, the days of direct interaction with a servlet container, which is just enough for Spring Microservice to run, are over. There are three servlet containers to choose from with Spring Boot:

• Apache Tomcat (tomcat.apache.org)
• Eclipse Jetty (eclipse.org/jetty)
• Undertow (undertow.io)

Each of these servlet containers has specific strengths. By default, Apache Tomcat is included in the Spring Boot Fat JAR. However, Spring Boot takes care of the instantiation and configuration. You no longer need to start an application server or a servlet container and then deploy a Spring application. The startup configuration and deployment steps are fully automated. 

Because Spring Boot represents a way of application packaging and distribution, a common Spring Boot application can always be converted into a traditional Spring Framework application and deployed as a Web Archive into a Servlet Container or Application server. This can be achieved by editing Maven's POM, modifying the dependencies and way of packaging.