Wildfly Swarm, towards maturity and a small contribution #wildfly #wildflyswarm
One of the projects I follow lately, is Wildfly Swarm. Eventually my request during this year's Devoxx in the JBoss BOF, to consider changing the name of the project, did not go through (due to the conflict with the famous Docker Swarm).
So what is Wildfly Swarm?
Simply put, is the Wildfly application server (app server of choice for many devs -including me), split into in several pieces - (modules or fractions as they are called), and made available to any developer to use them and assemble a new modular solution. You wont have to bundle or install the whole app server any more, just the layers and functionality you want. You can pick from a list of several sub-modules those that your application is going to leverage, pull their dependencies and assemble your final jar application along with your code. The model resembles a lot on what many teams and developers out there do with Spring Boot.
Wildfly and modularity - ahead of it's time
One side note, is that Wildfly is one of the few application servers that invested on its modularity and related infrastructure long before other technologies or containers emerged. The JBoss/ Wildfly code base throughout these years, changed a lot towards providing a flexible core with plug-gable modules and this is something we need to give credit to their development and design team for many years now. If you have worked on any project using Wildfly or JBoss you are already exposed to it's modules architecture and the simplified class and library loading features. So the application server and components were already modular by design and constructs, the only thing missing is to make it official and provide some extra tools and APIs to the end developer - to fully leverage this ability. That is Wildfly Swarm. The development is still ongoing. The official site can be found here, a long list of examples and code can be found here, the official documentation can be found here, twitter account here, and the mailing list can be found here.
ShrinkWrap - an excellent API
One of the advantages of using Wildfly Swarm, development wise, is the use of a very handy an excellent written API IMHO, called ShrinkWrap. ShrinkWarp emerged out of the Arquillian Project, and it is the API you use to build on the fly your testable archive which will be deployed on the fly to a app server run time. What a great fit in the context of Wildfly Swarm, where you can compose programmatically your end application.(There are other ways as well). I was always enjoying the beauty and simplicity of ShrinkWrap when developing test based on Arquillian and I am very happy to see it escape to other tools and technologies as well.
A small maven contribution
While I was going through the examples, trying to learn and play with Wildfly Swarm, I noticed that there was a small thing missing from the Maven perspective. Since there are a lot of modules (fractions) that eventually you can define as dependencies, in order to come up with your final solution, I was missing some help, in the form of a fractions Bill of Materials, so that you can import in your final POM and then pick whatever dependencies you may like. I decided to create an issue and provide a tiny pull request - with a proposed BOM. Happy enough the development team, progressed on this one fast enough and the latest version of Wildfly Swarm, features a new BOM for all Maven users. I have a small demo project (not something fancy, just to show case some things or play with some others in the future). You can find it here.
The main idea is that, in any new Wildfly Swarm based project, built with Maven, you can now import the specific BOM ( name bom) and you can have a concrete list along with version of the available fractions (components).
You can find the complete simple pom here.