DEV Community: Ankit Yadav

Using maven build profiles to generate different artifacts

Ankit Yadav — Wed, 20 Dec 2023 05:30:22 +0000

Want to use the same maven Pom file to create two or more different types of artifacts (jar/war etc.) based on some condition?

You can do it by Modifying pom files manually based on your requirement every time you build but this becomes tedious if you have to do it continuously.
Also, it will be a puzzle for developers who start working on the project when you are no longer there to guide.

We could use maven build profiles instead.

A Build profile is a set of configuration values, which can be used to set or override default values of Maven build. Using a build profile, you can customize build for different environments such as Production v/s Development environments.

Among other uses of build profiles, you can use this approach to:

Create builds using different parameters values
Create builds with different artifact types

Below I am going to show you a way with which you can use the maven profiles for the purpose of creating

A Jar library file to be used as a dependency by another project. OR
A War file to be deployed to the server directly.

Changes Required to the POM file for creating profiles:

There will be some fields that will require values as parameters instead of hardcoded values:
- artifactId - artifact id of the artifact created as end result
- packaging - to define the type of packaging like war or jar
- name - name of the artifact to be created
- description - description of the artifact
Now these values defined as parameters above will be passed actual values based on the build profile.
The first profile is for generating war package for the springboot project having id "generate-war" We have set activateByDefault as true for this, we want the default behaviour to be creation of war file.
The second is for generating library package to be used a library in other projects.
You can add the dependencies based on your requirements.



<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.16</version>
        <relativePath/> 
    </parent>
    <groupId>com.abc.test</groupId>
    <artifactId>${packaging.artifactId}</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>${packaging.type}</packaging>
    <name>${packaging.name}</name>
    <description>${packaging.description}</description>
    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--Other dependencies-->
    </dependencies>

    <profiles>
        <profile>
            <id>generate-war</id>
            <properties>
                <packaging.artifactId>test-api</packaging.artifactId>
                <packaging.type>war</packaging.type>
                <packaging.name>test-api</packaging.name>
                <packaging.description>TEST API project</packaging.description>
            </properties>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.springframework.boot</groupId>
                        <artifactId>spring-boot-maven-plugin</artifactId>
                    </plugin>
                    <!--You can any other plugins required for specific profile here-->
                </plugins>
            </build>
        </profile>
        <profile>
            <id>generate-library</id>
            <properties>
                <packaging.artifactId>test-api-lib</packaging.artifactId>
                <packaging.type>jar</packaging.type>
                <packaging.name>test-api-lib</packaging.name>
                <packaging.description>TEST API library</packaging.description>
            </properties>
            <build>
                <finalName>test-api-lib</finalName>
            </build>
        </profile>
    </profiles>

    <build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-install-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

To build using these profiles we use the -P parameter with the profile id as below:



mvn install -P generate-library



mvn install -P generate-war

Also if you are using intellij Idea then you can use the plugin as well to select the profile.

Hope this helps you if you ever face such a scenario!

Efficient API Testing using Postman: Collections

Ankit Yadav — Mon, 18 Dec 2023 14:01:19 +0000

Postman is an API platform for building and using APIs.

It offers various features that are useful for both developers and testers. One of the core features is Collections to store all your API requests.

A Collection represents a group of requests that are grouped by some criteria (some of them are discussed below).

The reason I am writing this specific post is because I have seen a lot of developers just putting in their requests randomly in the Postman, without any structure. So, when you need any specific request in the future, it takes ages to just get a working request from your existing Collections.
Also, these collections cannot be used by anyone other than the one who created them as no one will be able to understand what the requests mean or represent.

Here I am going to discuss about some basics of collections and how you can manage your postman collections, so that it is structured. To help you save time and create a sharable collection.

Criteria to arrange your collections

Domain Driven Design - As the name suggests, since most of the API will themselves be using the DDD, this can be a good starting point.
Along the lines of business - A company’s products and services have evolved over time and can point to patterns and standards that can help define your APIs and organization structure.
Team Centered Approach - Each team has its own collection.
Resource-Centered View - A lot of effort is already put into the API paths and schemas, the same can be used to groups requests into collections.
Focusing On Collaboration - If there are groups of requests that you would like to share with other team members, or open as public API, or some other restrictions, you can create collections for each of those groups.
Identifying your own approach - If you have some other approach that better suits your requirements like versioning, stages, governance, chose that.

An overview of Collections organised correctly, will help new team members get an overview of the complete application as well.

Let's see how you can manage your collections, once you have identified a criteria to organise. Here are some of the ways I have used myself.

Workspace

I have multiple workspaces based on the team/project I am working on:

A workspace for each Completed Project
Workspaces which I share with other people
My personal workspace for POC or things not relevant to any project, but my personal learnings.
A current in progress workspace for the project I am currently working on
An archive workspace to move all old API to it, when I feel it is not required right now but might be required later.

Collections

Some of the approaches that I have used for collections are:

Each project has its own collection
A sharable read only public collection for different teams to get data using our API
Collections based on Release targets

Folders

Folders can be used to groups requests inside a collection. Some of the folder structures that I have used are based on:

Stories
Resource paths
API
features
Application pages
Requests that are interdependent and might require to use data from each other

Requests

Almost all request variations are kept inside its own folder. The folder would have requests as follows:

GET Requests
POST Requests
PUT Requests
DELETE requests
any other request type
Different variations of these requests based on different paths

Examples

There is also a feature of examples which can be used to store the executed specific scenario. This includes: complete request with the request body & complete response details.
Each request will have at least one of the following:

working success scenario
Failure(error) scenario
only mandatory fields request scenario
all fields request scenario
Specific business scenarios
Any Complex Bug related scenarios
Response from different environments(Local, Dev, Staging, etc..)
Anything else that you think will save time or you would require reference to in future.

Benefits of managing your collections in a structured way

Easier to find specific requests
One click to run complete set of requests in a folder/Collection
Common authorization for all the requests in a folder/Collection
Common pre-request scripts for a folder/Collection
Common tests can be run on the run response for a folder/Collection
Common variables can be managed and used through a Collection
Can create a fork of a collections so that everyone can use the base collection as reference and making their own changes on it, also creating a Pull request, pulling changes added by other, maintain history for all changes.
View Changelog for a collection

Please do share your suggestions, that will help others improve productivity with Postman API testing.

Standardize code formatting with Spotless

Ankit Yadav — Sun, 31 Jul 2022 17:05:00 +0000

Organizing and formatting code as a standard for the whole team is important and useful. Without a standard being followed for formatting code within the project following problems:

Conflicts during updates from repository and during merge
Developers using their preferred formatting
Different auto format settings in IDEA showing more changes as when committing code

In order to setup a standard in regards to code formatting, we need to setup either a common configuration file to be imported by everyone or we can use something like Spotless which could be configured to use existing code formatting standards including Google Java Format and others.

Spotless is available for lots of languages like: Java, Groovy, Kotlin, Scala, C/C++, Python, Sql, Typescript

Here I am going to explain the usage of Spotless which we are using in our applications.

The setup is really simple and comprises of only two steps no matter you use Maven or Gradle:

Include the spotless dependency: "com.diffplug.spotless"
Configure the plugin based on what your formatting preferences
Make it part of build (optional but preferred)

Include the spotless dependency

Maven

<dependency>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
</dependency>

Gradle

dependencies {
    implementation("com.diffplug.spotless:spotless-lib:${spotlessLibVersion}")
    implementation("com.diffplug.spotless:spotless-plugin-gradle:${spotlessVersion}")
}

Configure the plugin

Maven

<plugin>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <configuration>
        <ratchetFrom>origin/develop</ratchetFrom>
        <java>
            <includes>
                <include>src/main/java/**/*.java</include>
                <include>src/test/java/**/*.java</include>
            </includes>
            <importOrder />
            <removeUnusedImports />
            <toggleOffOn/>
            <trimTrailingWhitespace/>
            <endWithNewline/>
            <indent>
                <tabs>true</tabs>
                <spacesPerTab>4</spacesPerTab>
            </indent>
            <palantirJavaFormat/>
        </java>
    </configuration>
</plugin>

Gradle

spotless {
    java {
        target fileTree('.') {
            include '**/*.java'
            exclude '**/build/**', '**/build-*/**'
        }
        toggleOffOn()
        palantirJavaFormat()
        removeUnusedImports()
        trimTrailingWhitespace()
        endWithNewline()
    }
}

Common configurations used in the above example for formatting

importOrder- All imports are ordered
removeUnusedImports - Unused imports are removed
toggleOffOn - toggle formatting in code by a comment
trimTrailingWhitespace - All trailing whitespaces in the code are removed
endWithNewline - The file ends with a new line

Execute spotless on code

Maven
mvn spotless:apply - To implement automated code formatting mvn spotless:check - To validate if code was formatted

Gradle

.\gradlew clean build spotlessApply - To implement automated code formatting .\gradlew clean build spotlessCheck - To validate if code was formatted

Reference: Github/spotless