Implementing a custom Maven Archetype to generate Spring Boot-based services (you are here)
Automating service provisioning and CI/CD using AWS Pipeline, Bitbucket and Terraform (work in progress)
1. OVERVIEW
Let’s say your organization is splitting the big monolithic application in multiple, smaller and more specialized microservices. Some of them will interact with a relational database and a message broker while others will communicate with a NoSQL database for instance.
This is a great opportunity to standardize the new deliverables in your company. You might want to develop some custom Spring Boot starters responsable for providing common Java application components, JSON-formatted logging, tracing, metrics, monitoring, resilience, RDBMS and APIs implementation support, helping with the application bootstrapping process and reducing common boilerplate code in each Spring Boot-based service.
Once you are using these Spring Boot starters in an application, how would you use them in a new service? Copy and paste and change the artifact ID? Removing unused dependencies? Clean up properties files and Java classes? Although this process works, it involves manual labor which is always tedious and error-prone.
In this guide I describe how to implement and use a custom Maven archetype, which uses a custom Spring Boot starter, integrated in a multi-module Maven setup to automate new projects generation.
In this specific case, default values will be used if not specified in the command to generating a project:
Archetype property
Description
archetypeVersion
The version of the archetype to use as prototype to generate a Maven project, defaulting to RELEASE
groupId
The group ID of the Maven project to be generated, defaulting to com.asimio.api
artifactId
The artifact ID of the Maven project to be generated, without a default value
version
The version of the Maven project to be generated, defaulting to 0-SNAPSHOT
Warning: Applications including RELEASE dependencies will bundle the latest version found in the Maven repository. Use them with caution.
A packaged fileSet means the included files will be generated in a folder structure prepended by the package property (defaulting to the groupId). For instance, if you use -DgroupId=com.acme to create a project from this archetype, the Java files will be generated in src/main/java/com/acme/.
A filtered fileSet means the included files will be processed as Velocity templates, expresions are will be evaluated, variables will be replaced, etc.. If filtered is false, files will be copied as is.
3.1. THE ARCHETYPE RESOURCES FILES
src/main/resources/archetype-resources is where you put the prototype files used as the source to generate a new application. They include pom.xml, Java classes, properties files, test classes, etc..
Notice ${groupId}Velocity variable? That’s the why filtered was set to true for the fileSet including src/main/java in the archetype metadata file. Once this folder is processed during application generation, assuming the groupId property was to to com.acme, the generated Java class should look like:
3.2. BUILDING THE ARCHETYPE
Lets build and install this Maven archetype locally so that it could be found in (~/.m2/repository) when generating a new Spring Boot-based service:
And now lets install version 1.0.4:
A better choice would be to deploy the archetype artifact to a Maven repository manager like Nexus or Artifactory or to an AWS S3 bucket for the archetype to be reused outside of your development station.
Important:
I can’t stress the importance of generating an application using this archeype as part of your CI / CD pipeline enough.
I strongly believe a change to the archetype or any Maven module included as a dependency, triggering a new build, should also trigger generating an application using said archetype and also building it, using mvn clean package for instance, to be sure generated services won’t fail.
If you don’t do so, it’s very likely that at some point the archetype is going to generate applications that either don’t compile or tests will start failing.
The version of the archetype to use, optional in this case because it was set to RELEASE in archetype-metadata.xml.
groupId
The group ID of the new project, optional in this case because it was set to com.asimio.api in archetype-metadata.xml.
artifactId
The artifact ID of the new project.
interactiveMode
Setting it to false prevents Maven from prompting to user to enter values to the previously described archetype properties, reading them instead from the command line or properties file.
If you look at newly created application asimio-api-demo’s pom.xml:
It includes one RELEASE dependency to keep this guide and series short but it’s expected to include many in-house RELEASE artifacts. A change to any of these dependencies will impact the applications that use them.
If asimio-cxf-swagger-springboot-starter artifact is updated, the next time asimio-api-demo gets built, even without any modification, it will bundle a new version. There is risk in doing so and it’s a trade-off.
With a RELEASE version, applications get new functionality and bug fixes without any change to its pom file. But a change to the signature of a public method in the dependency will also break the applications.
On the other hand, if an application use a specific version, such as 1.0.4, there is no risk in it failing as the library keeps getting updated, but the application won’t get new functionality from this library either and there might be reluctance to uplift a dependency to 5.0.16, two years after 1.0.4 was released.
Thanks for reading and as always, feedback is very much appreciated. If you found this post helpful and would like to receive updates when content like this gets published, sign up to the newsletter.
6. SOURCE CODE
Accompanying source code for this blog post can be found at:
Orlando L Otero is a Sr Software Engineer Consultant focusing on integration, modernization, cloud adoption and migration, microservices, API design and implementation, and agile delivery.