Maven Archetype: Optimizing Methodologies

by Alex Nasarre on Jan 14, 2019

One of the main challenges our Professional Services team faces is to adapt Strands products to our end clients’ needs.

For this purpose, our Technology team develops and provides us with the latest stable version of our products and we make the necessary changes to fit the client’s requirements. These requirements are both functional and architectural.

Detecting improvements

 After carrying out this process a few more times than we’d like to admit, it became clear that it was quite repetitive, and that we were doing it manually for the most part. Setting up a new project for a client could take up to a day, and we sometimes missed a dependency or added something we didn’t need, only to discover this a few days later. To improve this process, we decided to automate it in a way that it would:

  1. Reduce the time needed to setup a client’s project

  2. Simplify the creation of new projects for clients, being able to parametrize:

    1. Project name, following a standard

    2. Modules to implement

    3. Database connection details

    4. Infrastructure (database vendor, application server, etc)

  1. Standardize project creation

    1. Naming conventions

    2. Inherit all coding standards and core dependencies from Strands main products

Maven Archetype to the rescue

After considering several options, we decided to proceed with Maven Archetype, a system which allowed us to define a template for every new client project. This archetype would be developed as a module of our Strands Parent project with the following structure:

main_project/

└── archetype_module/

├── pom.xml

└── src

   └── main

       └── resources

           ├── archetype-resources

           │ ├── pom.xml

           │ └── src

           └── META-INF

               └── maven

                   └── archetype-metadata.xml

 

Setting it up in Strands Finance

Firstly, we configured the pom on the archetype-module directory. This needed to have the packaging type “maven-archetype” and has our core backend parent, com.strands.finance, as a parent.

<groupId>foo.bar.xyz</groupId>

<artifactId>archetype_module</artifactId>

<packaging>maven-archetype</packaging>

<parent>

<groupId>com.strands.finance</groupId>

<artifactId>finance</artifactId>

<version></version>

</parent>

<name>archetype_module</name>

We then configured the archetype-metadata.xml file, which contains important details in three sections:

  • RequiredProperties: We defined some global variables here that helps us configuring the each project with different customizations. Most of the variables here will be asked to the user when creating the project, and others will be generated based on them.

  • FileSets: Here, we determined what file extensions were going to be exported to the project, managed the encoding, and ascertained whether we needed to inject the variables or not.

  • Modules: These are the modules that were going to be created for the project. These modules can be parametrized to adapt their names to the client’s codename.

<archetype-descriptor>

<requiredProperties>

<requiredProperty key="foo">

<defaultValue>bar</defaultValue>

<validationRegex>foo.bar.[a-z]{3}</validationRegex>

</requiredProperty>

</requiredProperties>

<fileSets>

<fileSet encoding="UTF-8" filtered="true">

<directory></directory>

<includes>

<include>*.yml</include>

<include>*.sh</include>

<include>*.xml</include>

<include>*.md</include>

</includes>

</fileSet>

</fileSets>

<modules>

<module id="${prefix}-${type}-product"

dir="__prefix__-__type__-product"

name="${prefix}-${type}-product">

<fileSets>

<fileSet filtered="true" encoding="UTF-8">

<directory>src/main/java</directory>

<includes>

<include>**/*.java</include>

</includes>

</fileSet>

</fileSets>

</module>

</modules>

</archetype-descriptor>

Results

On executing the archetype, we were asked a few questions about the project we wanted to generate. These fill the variables we previously defined in archetype-metadata.xml and works like a wizard, allowing us to define:

  1. Product to implement (PFM, BFM, etc)

  2. Module providers (Strands Invoicing, external invoicing, etc)

  3. Database providers (Oracle, PostgreSQL, etc)

  4. Database connection details

  5. Naming conventions

    1. Client’s name as a three-character abbreviation (XYZ)

    2. Project and module names (xyz-pfm-budgets)

We also parametrized and included all the necessary resources (directories and files) in the archetype-resources directory to have access to:

  • Basic directories and files from our backend core.

  • API Documentation based on Swagger.

  • DockerFiles to be able to run the project as a docker image.

  • Autogeneration of JenkinsFile to create the necessary CI jobs.

  • .gitignore file

  • Autogeneration of README files including all necessary information to work on the new project.

Next steps

Once this implementation had been carried out with the Backend module, and as a direct result of its “core” status, the outcome was very positive. For that reason, a scenario in which all Strands modules are prepared and ready for installation is being considered, available on a drop-down menu for all the currently supported infrastructures.

On the one hand, this will allow the technical team constant access to the latest version, to be able to develop customized solutions for specific customers without delay. On the other hand, Strands will be able to offer the ‘out-of-the-box’ version of a product, adapted to suit individual customer needs much more quickly.  

For the above scenario to be possible, improving both time-to-market and time-to-delivery, the following options are being taken into consideration:

 • Improve the existing archetype to increase the number of capabilities and add-ons, offer the possibility of selecting the chosen application server to automatically generate the necessary configuration.  

• Extend the implementation of archetypes for all other Strands’ products (realtime, ui) etc.

This new project has been improved greatly since it began, and we are happy with the decision we made to pursue this idea, so much so that we are now extending this to other projects and teams within Strands. We have continued to work on the archetype project itself, adding new functionalities and options, and offering more control over the application server and database configurations.

 The original version of this post can be found on Strands Tech Corner on Medium 

About Alex Nasarre

Get the latest updates here

SUBSCRIBE HERE