Setting up a mono repo containing Java and Kotlin based Spring Boot minions

Do you have to deal with version hell in your microservice (we call them minions) farm? A mono repo can be the solution. I heard about this a short time ago and I do recognise the challenges the mono repo is about to solve; helping to solve versioning problems with minions and allow developers to do atomic commits.

I’m not going deep into the details and pro’s-and-con’s of the mono repo. There is a lot to be found on the Internet and there is a page on Wikipedia as well. This article shares a way to create a mono repo for Spring Boot based minions.

This article shows how to setup a mono repo consisting of one backend component and two frontend components, all Spring Boot based and using Java as well as Kotlin.

The following recipe shows how to setup the mono repo;

First create a root pom file. The file defines a pom package type and does not contain any dependency definitions. Why? General definition apply for all minions at the same time and you don’t want to be forced to update all minions at once when you only want to update the Spring version of one minion. You can define some versions here if they apply to all you minions, it is easy to override such a version number on a deeper level if needed.

The only part that is really needed is the <modules> element, it defines which modules belong to the tree. And yes, I’m a big fan of gitflow and that is also to be defined on the root level.

A backend service

The first real component is the minion we want to create. Let’s say a backend service. We want this backend service to have a REST endpoint and we want to share the object model for that rest service to be available for it’s clients. So, we are going to create an intermediate pom module. Again it defines a pom package.

Please don’t forget to define this module in the root pom!

Now we can create the sub module containing the object model for the endpoint of out service. For this interface it my choiche to create it as a seperate module, just to be able to import it in the clients. A disadvantage is that this may lead to strong coupling, something you may want to avoid. Nevertheless, if you want to do it this way this can be an example.

This module is a sub module of the backend-parent module we just defined.

And again, don’t forget to add this module to it’s parent!

This pom file is created kotlin-archetype-jvm template, you may choose another one. Please check the executions defined in the kotlin-maven-plugin, the test-compile execution is needed and is not a part of the default plugin settings. Your tests won’t run if this phase is not defined.

In the interface module we do have to define the object model only

Just plain old Kotlin objects (are the called Poko’s?)

Now we can create our first Minion, the backend service minion. It is a good idea to create this minion right from start.spring.io and modify the file afterwards. The module is to be created a a child of the backend parent module (so next to the interface module) and again, don’t forget to add this module in the… (yes, you know). Our new pom file should look like this:

Let’s walk through the modifications:

1. In the properties part I choose a different spring-boot.version. It overrides the property from the root pom. Just for demo 🙂
2. Then the dependency management element. We do need this one because we do not inherit it from the parent pom.
3. The executions-element should be added to the kotlin-maven-plugin.
4. And finally, the maven-surefire-plugin should be added.

It is important to recognise that the last two steps can easily be forgotten. The build will not fail without them. However, if one step is forgotten the test will not run! Therefor it is always a good idea to test these build scripts with a failing test.

The repositories elements are added because this example is based on a beta version of Spring.

The controller self is quite simple. No further comments.

After creating the backend service, it is time to create the frontend service. For this component we do create a Java based Spring module right under the root project.

The pom file will look like this:

Just like for the backend application, the pom file has the root pom as it’s parent, the dependencyManagement-element and the surefire plugin. However, the Kotlin-mavenplgin is replaced by the maven-compiler-plugin. This plugin does compile the main code as well as the test code by default.

Now that we have a server and a client minion, both sharing an interface definition, we can build it all using maven clean install. From here you can create a feature branch, update the code (like updating the interface object model) and build-and-test all minions. Once the it works, you can merge it to the develop-branch!

All code can be found on GitHub. Happy coding!