< Java
Tip >

DEVELOPING A MAVEN ARCHETYPE FOR MICROSERVICES, PART 2

Harry Klerks
Hello, welcome and thank you for reading this second instalment of our series on developing a Maven archetype for microservices. It has been a while since we published the first part of this series so perhaps you want to refresh your memory first.

Developing a Maven archetype for microservices, part 1

Addendum
There was a minor omission in part1. To run an archetype you must also include a archetype version. Like this:

mvn archetype:generate -DarchetypeGroupId=com.bongaro.platform -DarchetypeArtifactId=bongaro-microservice-archetype -DarchetypeVersion=2017.1.0-SNAPSHOT

At the end of that first part we could generate a very simple project structure that contained just a single pom.xml file.In this part we will add some more substantial content to the archetype. Since we are building according to a Domain Driven Design (DDD) architecture, let's start by adding a module for the domain.Let's assume that we have to build a microservice by the name of  'People' and that it has a single aggregate class by the name of 'Person'.

Module ms-people-domain

The domain module contains the classes that make up the domain and exposes interfaces for factories, repositories and boundaries. The archetype project has the following structure by now:

Note the directory by the name of __rootArtifactId__-domain. When a file or directory name is a variable, the notation __VARIABLENAME__ is used by the archetype plugin. Note also that the variable name rootArtifactId is one of the few default variables known to the artefact plugin. For example, when we generate code for this archetype and input ms-people for the artifactId, the directory name will be resolved to ms-people-domain.

For now we generate just a simple Java class com.bongaro.diagora.people.domain.core.Person that contains a single readonly property name, like this:

Note the ${package} property placeholder. The property  package is another example of a default property for the archetype plugin. It contains the value you provide when prompted at runtime.

The file pom.xml of the domain module looks like this:

That still looks rather straightforward, does it not?

Finally, the archetype-metadata.xml file looks like this now:

We have added a  module element to generate the ms-people-domain module. Note that the  id and name attributes can resolve the ${rootArtifactId} property notation, while the dir attribute must use the __rootArtifactId__ notation. The archetype plugin will generate a separate directory for the module and also add a module element to the parent pom.xml file.

We have added two file sets to this module. The first one copies and filters all files with an extension .java to the generated output, while the second one does the same for the pom.xml file. Note the different values for the packaged attribute. If true, files will be prepended by the value of the package default property. If false no prepending will take place.

Running the archetype

If we run the archetype and subsequently build the generated project, we see the following on disk:

Summary

In this second part of our series, we added the first simple, but essential module to our multi-module Maven project for the micro service people. By so doing, we have created a solid base to further develop our archetype.

Thank you for reading and see you in Part 3!

We love to hear your opinion