Maven profiles – Operating Systems (OS) specific build profiles

By
Maven is a powerful build framework and it allows us to customize every aspect of build with simplicity.

In this article, we’ll learn about how to create different build profiles for windows and Mac OS. The same concept can be replicated to other operating systems or environment specific builds.

Let’s define a use case.

Let’s say we have project in which we want to compile and package Angular 2+ project using maven build. Angular 2+ project is dependent on Node.js (npm) and Angular CLI (ng CLI). We can use Maven Exec plugin for invoking npm and ng CLI commands.

On Mac OS “npm” and “ng” commands works without any additional extension. To run same commands on Windows operating system we need to append .cmd extension. This means if we have mixed folks in development team who uses both Windows and Mac OSx then every time pom.xml file needs to be updated. What if someone pushes this file to central code repository? This will obviously break the builds on CI/CD (e.g. Jenkins server). This is just one scenario, there may be other use cases where build command/process has to be different based on operating systems or environment and it is not good idea to modify pom.xml file locally for build and leave room for accidental commits/push. This is where Maven profiles comes handy.

Let’s continue with same Angular 2+ build example. On Mac OS, the build section (that is responsible for building Angular project using Maven exec plugin) of pom.xml file would look like:
        

<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 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <!-- Omitted remaining pom.xml for simplicity -->

 <plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <executions>
   <!-- Execute UI Build as part of standard Maven "generate-resource" phase -->
   <execution>
    <id>ui-npm-install</id>
    <configuration>
     <workingDirectory>.</workingDirectory>
     <executable>npm</executable>
     <arguments>
      <argument>install</argument>
     </arguments>
     <workingDirectory>${basedir}</workingDirectory>
    </configuration>
    <phase>validate</phase>
    <goals>
     <goal>exec</goal>
    </goals>
   </execution>
   <execution>
    <id>ui-aem-build</id>
    <configuration>
     <workingDirectory>.</workingDirectory>
     <executable>ng</executable>
     <arguments>
      <argument>build</argument>
      <argument>--prod</argument>
      <argument>--outputHashing</argument>
      <argument>none</argument>
     </arguments>
     <workingDirectory>${basedir}</workingDirectory>
    </configuration>
    <!--<phase>prepare-package</phase> -->
    <phase>generate-sources</phase>
    <goals>
     <goal>exec</goal>
    </goals>
   </execution>
   <execution>
    <id>npm-clean</id>
    <configuration>
     <workingDirectory>.</workingDirectory>
     <executable>rm</executable>
     <arguments>
      <argument>-rf</argument>
      <argument>node_modules</argument>
     </arguments>
     <workingDirectory>${basedir}</workingDirectory>
    </configuration>
    <!--<phase>prepare-package</phase> -->
    <phase>install</phase>
    <goals>
     <goal>exec</goal>
    </goals>
   </execution>
  </executions>
 </plugin>

 <!-- Omitted remaining pom.xml for simplicity -->
</project>

Look at the line # 18, 33, 52 and 54. These commands are OS dependent and if we run a maven build with this configuration on Windows, it’ll fail.

To handle this in Maven way, we could create separate profile for Max OS and Windows. Following pom.xml file shows an example of OS specific build profiles.
        
<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 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>  
    <!-- Omitted remaining pom.xml for simplicity -->
   <profiles>
     <!-- Max OSX specific build profile -->
    <profile>
     <id>macOSBuild</id>
     <activation>
       <!-- Profile is active by default -->
      <activeByDefault>true</activeByDefault> 
     </activation>
     <build>
         <plugin>
           <groupId>org.codehaus.mojo</groupId>
           <artifactId>exec-maven-plugin</artifactId>
           <executions>
             <!-- Execute UI Build as part of standard Maven "generate-resource" phase -->
             <execution>
               <id>ui-npm-install</id>
               <configuration>
                 <workingDirectory>.</workingDirectory>
                 <executable>npm</executable>
                 <arguments>
                   <argument>install</argument>
                 </arguments>
                 <workingDirectory>${basedir}</workingDirectory>
               </configuration>
               <phase>validate</phase>
               <goals>
                 <goal>exec</goal>
               </goals>
             </execution>
             <execution>
               <id>ui-aem-build</id>
               <configuration>
                 <workingDirectory>.</workingDirectory>
                 <executable>ng</executable>
                 <arguments>
                   <argument>build</argument>
                   <argument>--prod</argument>
                   <argument>--outputHashing</argument>
                   <argument>none</argument>
                 </arguments>
                 <workingDirectory>${basedir}</workingDirectory>
               </configuration>
               <!--<phase>prepare-package</phase> -->
               <phase>generate-sources</phase>
               <goals>
                 <goal>exec</goal>
               </goals>
             </execution>
             <execution>
               <id>npm-clean</id>
               <configuration>
                 <workingDirectory>.</workingDirectory>
                 <executable>rm</executable>
                 <arguments>
                   <argument>-rf</argument>
                   <argument>node_modules</argument>
                 </arguments>
                 <workingDirectory>${basedir}</workingDirectory>
               </configuration>
               <!--<phase>prepare-package</phase> -->
               <phase>install</phase>
               <goals>
                 <goal>exec</goal>
               </goals>
             </execution>
           </executions>
         </plugin>   
     </build>
    </profile>
    
    <!-- Windows OS specific build profile -->
      <profile>
        <id>winOSBuild</id>
        <activation>
          <!-- Profile is NOT active by default -->
          <activeByDefault>false</activeByDefault>
        </activation>
        <build>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <executions>
              <!-- Execute UI Build as part of standard Maven "generate-resource" phase -->
              <execution>
                <id>ui-npm-install</id>
                <configuration>
                  <workingDirectory>.</workingDirectory>
                  <executable>npm.cmd</executable>
                  <arguments>
                    <argument>install</argument>
                  </arguments>
                  <workingDirectory>${basedir}</workingDirectory>
                </configuration>
                <phase>validate</phase>
                <goals>
                  <goal>exec</goal>
                </goals>
              </execution>
              <execution>
                <id>ui-aem-build</id>
                <configuration>
                  <workingDirectory>.</workingDirectory>
                  <executable>ng.cmd</executable>
                  <arguments>
                    <argument>build</argument>
                    <argument>--prod</argument>
                    <argument>--outputHashing</argument>
                    <argument>none</argument>
                  </arguments>
                  <workingDirectory>${basedir}</workingDirectory>
                </configuration>
                <!--<phase>prepare-package</phase> -->
                <phase>generate-sources</phase>
                <goals>
                  <goal>exec</goal>
                </goals>
              </execution>
              <execution>
                <id>npm-clean</id>
                <configuration>
                  <workingDirectory>.</workingDirectory>
                  <executable>rmdir</executable>
                  <arguments>
                    <argument>/s</argument>
                    <argument>node_modules</argument>
                  </arguments>
                  <workingDirectory>${basedir}</workingDirectory>
                </configuration>
                <!--<phase>prepare-package</phase> -->
                <phase>install</phase>
                <goals>
                  <goal>exec</goal>
                </goals>
              </execution>
            </executions>
          </plugin>     
        </build>
      </profile>  
   </profiles>
   <!-- Omitted remaining pom.xml for simplicity -->
  </project>

Few important observations

·      We have moved the plugin “exec-maven-plugin” configuration inside XML tag
·      Created two profiles “macOSBuild” and “winOSBuild” (line 9 and 78 respectively)
·      “macOSBuild” profile is active by default (line 12). This means on Mac OS, we can simply run the “mvn clean install” command and Mac profile will be automatically picked up for build
·      To execute build on Windows OS, we need to explicitly tell maven to use “winOSBuild” profile. This can be done via “mvn clean install -PwinOSBuild”

I hope this simple concept will help you to avoid manual changes of pom.xml and keep your project away from accidental risk of build failures.

Comments

Post a Comment

Popular posts from this blog

Custom synchronisation or rollout action for blueprint ?

By
Image
Blueprint is an important feature for all those sites which needs to deals with multiple locale and region specific sites. Consider that we have 20 different regional sites and each regional site have 2 locales (English and regional language). Now let’s say you need to do a small update on a English locale page and that changes is required on all sites, there will be 20 pages that you’ll need to visit and make changes one by one (if you have not used blueprint and live copy). With blueprint  we can create a master copy (which is called as blueprint) and create many live copies (which are actual sites) and the benefit you get is that as soon as you do any change in blueprint that same change will be propagated to all live copies pages when changes are rolled out by authors…this is cool. With blueprint you’ll need to apply changes only to English locale page on blueprint and all English locale pages (live copies) will receive that change implicitly. So, how this whole thing works? W
Read more

AEM as a Cloud Service (AEMaaCS) – Architecture Overview

By
Image
AEM as a Cloud Service (AEMaaCS) – Architecture Adobe Experience Manager (AEM) is one of the leading CMS from Adobe and is part of Adobe Experience Cloud (AEC). The Adobe Experience Manager (AEM) web content management offers a set of capabilities for creating, managing, delivering, and personalizing content across various digital marketing channels, including web, mobile, and email.  Before we dive into architecture of AEM as a Cloud Service (AEMaaCS) we need to understand why AEMaaCS is needed and how it is different as compared to classic AEM. To understand this, we’ll first look at: Evolution/history of AEM Challenges with traditional/classic AEM (the AEM that majority of us have used from last 10-12 years) Evolution/History of AEM The software was originally launched in early 2000 as Communiqué (CQ) by Day Software of Basel, Switzerland. After CQ 5.3 had been released, Day Software was acquired by Adobe Systems in 2010 then CQ became Adobe Experience Manager. From
Read more

AEM as a Cloud Service (AEMaaCS) – Quick Introduction

By
Image
AEM as a Cloud Service (AEMaaCS) – Introduction If you are working in content management space, you must have heard of Adobe Experience Manager (AEM, previously known as CQ5). It is one of the core products offered by Adobe as part of their Adobe Experience Cloud. AEM has evolved over the time from all perspectives (features, maturity, stability, integration with other products and deployment model).   As of today, organizations have 3 options to deploy AEM: AEM on premisses AMS – Adobe Managed Service (mainly hosted on AWS) AEM as a Cloud Service (AEMaaCS)  Focus of this article will be on AEM as a Cloud Service (AEMaaCS). Adobe Experience Manager as a Cloud Service is a new generation software-as-a-service for AEM by Adobe.   AEMaaCS is based on the leading solution Adobe Experience Manager (AEM) and offers outstanding content management (CMS) capabilities and digital asset management (DAM) for marketing and communication teams.   The solution has been entirely designed for the cloud
Read more

AEM - Query list of components and templates

By
Some time while migration or for auditing purposes we need to know where a particular component/template or any other resource have been used. Have you ever wondered about how to fetch a list of all the paths where a particular component or template is being used? I this short article I am going to show a quick way to write a utility with which you can get list if paths (actual resource nodes) where a targeted resource is being used. Here is the code snipped: public void getResourceListHelper(Resource parentResource , String targetSearchPropertyKey ,  String targetSearchPropertyValue , List components ) {      Resource childResource ; for (Iterator resourceChildrenIter = parentResource .listChildren(); resourceChildrenIter .hasNext();  getResourceListHelper ( childResource, targetSearchPropertyKey, targetSearchPropertyValue, components)) { childResource = (Resource) resourceChildrenIter .next(); ValueMap childProperties = (ValueMap) childResource .adap
Read more