What has just happened here?

The application works indeed. Let's look step by step what has just happened:

1. Maven build has been run. A standard maven package plugin has created the war archive, which included classes described previously (and which can be as well deployed into the standard application server).
2. The Swarm plugin built a runtime for our application. The runtime is based on WildFly-core and contains only the libraries needed by the service application.
3. The plugin has built a runnable JAR, which combines the runtime and the application.
4. Since we have specified the run goal, the plugin has started the service immediately after its creation.

Let's take a look at the target directory to note the build output:

As you can see in the preceding screenshot, besides the standard Maven target artifact, one more JAR is created: swarm-hello-world-1.0-swarm.jar. This is the runnable microservice. Its name is created from the archive's name to which the Swarm suffix is added. Also, note that the size of the service is 47,5 MB. It is slightly bigger than WildFly web-server profile. The reason for that is that some more libraries (enabling REST services) have to be added to the server.

This example was supposed to give you an initial feel for WildFly Swarm. As you see, the responsibility of the developer here is to implement a business functionality and configure the Swarm maven plugin. Swarm takes care of the rest: it creates the server with all libraries necessary to make those features work and connects the archive with this server to create a runnable microservice. Owing to this convention-over-configuration style and automatic server creation, a lot of the configuration burden is taken away from the developer so he/she can concentrate on business functionality development. Obviously, this standard behavior can be changed—you will learn more about it in subsequent parts of this book.