Maven Interview Questions and Answers for 2025

In Maven, you can use profiles to specify different build configurations for different environments or scenarios. Profiles are defined in the pom.xml file using the <profiles> element and can be activated in a number of ways. 

To define a profile in Maven, you can use the following syntax: 

<profiles> 
  <profile> 
    <id>profile-name</id> 
    <build> 
      <!-- configuration for this profile goes here --> 
    </build> 
  </profile> 
</profiles> 

You can then activate a profile in one of the following ways: 

By specifying the -P command-line option when running Maven, followed by the profile ID. For example:  

mvn clean install -P profile-name 

By setting the activeProfiles element in the settings.xml file. For example: 

<settings> 
  <activeProfiles> 
    <activeProfile>profile-name</activeProfile> 
  </activeProfiles> 
</settings> 

By specifying the MAVEN_OPTS environment variable with the -P option. For example: 

MAVEN_OPTS=-P profile-name 

You can also specify activation conditions for profiles, which allow Maven to automatically activate a profile based on certain criteria, such as the presence of a system property or the value of an environment variable. 

To determine the location where Maven will output compiled class files and other build artifacts, you can use the <outputDirectory> element inside the <build> element of your pom.xml file. An example of how to use this element is: 

<build> 
  <outputDirectory>build/classes</outputDirectory> 
</build> 

This will configure Maven to place the build output in the build/classes directory. By default, Maven uses the target directory as the build output directory, but you can override this by specifying a different directory in the pom.xml file. 

It's also possible to specify a separate output directory for test class files and other test artifacts using the <testOutputDirectory> element. 

To specify a custom directory layout in Maven, you can use the <build> element in your pom.xml file. Specifically, you can use the <directory> element to specify the root directory for the project and the <outputDirectory>, <testOutputDirectory>, and other related elements to specify the locations of various build artifacts. 

For example, to specify a custom directory layout with the root directory at myproject and the output directories at myproject/build/classes and myproject/build/test-classes, you can use the following syntax: 

<build> 
  <directory>myproject</directory> 
  <outputDirectory>myproject/build/classes</outputDirectory> 
  <testOutputDirectory>myproject/build/test-classes</testOutputDirectory> 
</build> 

You can also specify custom directories for other build artifacts, such as resources and plugins, using the appropriate elements in the <build> section of the pom.xml file. 

It's worth noting that Maven follows a standard directory layout by default, but you can override this layout by specifying custom directories in the pom.xml file.

To specify a custom version number for your project in Maven, you can use the <version> element in the <project> element of your pom.xml file. 

For example, to set the version number to 1.0.0-SNAPSHOT, you can use the following syntax: 

<project> 
  <version>1.0.0-SNAPSHOT</version> 
  <!-- other elements go here --> 
</project> 

The version number you specify should follow the conventions set by the Apache Maven team, which include the use of a major version number, a minor version number, and a patch number separated by dots (e.g., 1.2.3). You can also use the -SNAPSHOT suffix to indicate that the version is a work in progress and may change. 

It's worth noting that the version number you specify will be used to uniquely identify your project and its artifacts, so it's important to choose a version number that is appropriate for your project and follows the conventions set by Maven. 

To specify a different version of a dependency for a specific profile in Maven, you can use the <dependency> element within the <dependencies> element of the <profile> element in your pom.xml file. 

For example, to specify a different version of the com.example:foo dependency for the test profile, you can use the following syntax: 

<profiles> 
  <profile> 
    <id>test</id> 
    <dependencies> 
      <dependency> 
        <groupId>com.example</groupId> 
        <artifactId>foo</artifactId> 
        <version>1.0.0</version> 
      </dependency> 
    </dependencies> 
  </profile> 
</profiles> 

This will configure Maven to use version 1.0.0 of the foo dependency when the test profile is activated. You can also specify different versions of other dependencies in the same way. 

It's worth noting that the <dependencies> element within a profile will override any dependencies defined in the <dependencies> element outside of a profile, so you can use this technique to selectively override dependencies for different profiles. 

A common question in Maven Interview Questions, don't miss this one. The -D flag can be used when launching Maven from the command line to specify system properties. Using the following command, for instance, you might change the foo property's value from foo to bar: 

mvn -Dfoo=bar clean install 

Additionally, you can modify system properties in your Maven installation's settings.xml file or pass a file containing system properties by using the -s flag. Several Maven settings, like the project version, the directory holding dependencies, and the location of the local repository, are configured using system properties. Additionally, you may utilize them to pass in custom values that can be accessed from the code of your project or the POM.

Using the -e flag while executing Maven from the command line allows you to provide environment variables. The following command, for instance, could be used to set the foo environment variable to bar: 

mvn -e -Dfoo=bar clean install 

You can also set environment variables in the operating system where Maven is running. These environment variables can then be accessed from within the POM or your project's code using standard Java system property access methods. 

Keep in mind that environment variables set using the -e flag will only be available for the current Maven execution. To make environment variables permanently available, you'll need to set them in the operating system where Maven is running. 

It's also worth noting that environment variables have a lower priority than system properties, so if you have a system property and an environment variable with the same name, the system property will take precedence. 

To specify a Maven property that can be changed during the build process, you can utilize the -D flag when running Maven from the command line, similar to how you would with any other system property. As an example, to set the foo property to bar, you can use the command:  

mvn -Dfoo=bar clean install 

This will set the foo property to bar for the current build. However, you can also specify a different value for foo when running the build, like this: 

mvn -Dfoo=baz clean install 

This will use baz in place of the value of foo that was set in the POM. 

Additionally, it is possible to define default values for properties in the POM, which may be overridden by specifying the property in the settings.xml file or with the -D switch. This can be helpful if you want to provide a property with a default value but let users change it when creating the project. 

To specify a property that is only available in a specific profile in Maven, you can use the <properties> element in the <profile> element. For example: 

<profiles> 
  <profile> 
    <id>dev</id> 
    <properties> 
      <propertyName>devValue</propertyName> 
    </properties> 
  </profile> 
</profiles> 

You can then reference this property in your POM like this: ${propertyName}. When the "dev" profile is activated, the property will be set to "devValue". If the "dev" profile is not active, the property will not be set and will have no value.

To specify a resource directory in Maven that should not be included in the final package, you can use the <excludes> element in the <resources> element in your POM file. This will exclude certain resources from being copied into the target directory when Maven builds your project. 

Here's an example of how you can specify a resource directory to be excluded: 

<build> 
  <resources> 
    <resource> 
      <directory>src/main/resources</directory> 
      <excludes> 
        <exclude>**/unwanted_resource_directory/**</exclude> 
      </excludes> 
    </resource> 
  </resources> 
</build> 

This will exclude the unwanted_resource_directory and all of its contents from being included in the final package. 

To specify a filter in Maven that replaces placeholders in a file with values from a property file, you can use the <filters> element in the <resources> element in your POM file. This will allow you to define a property file that contains placeholder values and specify which files in your project should have those placeholders replaced. 

Here's an example of how you can specify a filter in Maven: 

<build> 
  <resources> 
    <resource> 
      <directory>src/main/resources</directory> 
      <filters> 
        <filter>path/to/property_file.properties</filter> 
      </filters> 
    </resource> 
  </resources> 
</build> 

This will apply the filter to all files in the src/main/resources directory, replacing any placeholders with the corresponding values from the property_file.properties file. 

To define a placeholder in a file, you can use the ${placeholder} syntax. For example, if the property_file.properties file contains a property called apiKey with a value of abc123, then any occurrences of ${apiKey} in your project's files will be replaced with abc123 during the build process. 

In order to run Selenium tests using the Maven Surefire Plugin, you must first add the plugin to your pom.xml file. To do this, you can insert the below code snippet within the <build><plugins> section: 

<plugin> 
    <groupId>org.apache. Maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <version>3.0.0-M3</version> 
    <configuration> 
        <suiteXmlFiles> 
            <suiteXmlFile>testng.xml</suiteXmlFile> 
        </suiteXmlFiles> 
    </configuration> 
</plugin> 

Next, you will need to create a testng.xml file in the root directory of your project. This file will contain the configuration for your Selenium tests, including the test class names and any parameters you want to pass to your tests. 

To run your Selenium tests using the Maven Surefire Plugin, open a terminal and navigate to the root directory of your project. Then, simply run the following command: mvn test. 

This should trigger the Maven Surefire Plugin to run your Selenium tests using the configuration specified in your testng.xml file. This is a common Maven interview question for Selenium testers, so it's a good idea to have a solid understanding of how to configure the Maven Surefire Plugin to run Selenium tests. 

In order to create a custom lifecycle in Maven, you must create a bindings.xml file in the ${basedir}/src/main/resources/META-INF/plexus directory. This file will define your custom lifecycle, including the phases it consists of. 

As an example, let's say you want to create a lifecycle called my-lifecycle with the phases compile, test, and package. The bindings.xml file for this custom lifecycle would include the following: 

<lifecycles> 
  <lifecycle> 
    <id>my-lifecycle</id> 
    <phases> 
      <phase> 
        <id>compile</id> 
        <bindings> 
          <binding> 
            <phase>compile</phase> 
          </binding> 
        </bindings> 
      </phase> 
      <phase> 
        <id>test</id> 
        <bindings> 
          <binding> 
            <phase>test</phase> 
          </binding> 
        </bindings> 
      </phase> 
      <phase> 
        <id>package</id> 
        <bindings> 
          <binding> 
            <phase>package</phase> 
          </binding> 
        </bindings> 
      </phase> 
    </phases> 
  </lifecycle> 
</lifecycles> 

To use your custom lifecycle, you will need to specify it in your pom.xml file using the <lifecycleMappingMetadata> element. For example: 

<build> 
  <plugins> 
    <plugin> 
      <groupId>org.apache. Maven.plugins</groupId> 
      <artifactId>maven-clean-plugin</artifactId> 
      <version>3.1.0</version> 
      <executions> 
        <execution> 
          <id>default-clean</id> 
          <phase>my-lifecycle</phase> 
          <goals> 
            <goal>clean</goal> 
          </goals> 
        </execution> 
      </executions> 
    </plugin> 
  </plugins> 
</build> 

Now, when you run mvn my-lifecycle, Maven will execute the compile, test, and package phases in that order. It's important to note that you can only specify a custom lifecycle in your pom.xml file, not on the command line. 

To specify a custom goal in Maven and bind it to a lifecycle phase, you will need to create a new Maven plugin and add it to your pom.xml file. The plugin should have a goal element that defines your custom goal and a phase element that specifies the lifecycle phase you want to bind the goal to. 

Here's an example of a Maven plugin that defines a custom goal called my_goal and binds it to the package phase of the default lifecycle: 

<build> 
  <plugins> 
    <plugin> 
      <groupId>com.example</groupId> 
      <artifactId>my-maven-plugin</artifactId> 
      <version>1.0-SNAPSHOT</version> 
      <executions> 
        <execution> 
          <goals> 
            <goal>mygoal</goal> 
          </goals> 
          <phase>package</phase> 
        </execution> 
      </executions> 
    </plugin> 
  </plugins> 
</build> 

To bind your custom goal to a different lifecycle phase, simply specify the desired phase in the <phase> element. This is a common Maven interview question for DevOps engineers, so it's important to have a good understanding of how to specify custom goals and bind them to lifecycle phases. 

You must first create a new Maven plugin and provide the desired group in the groupId> section of the plugin's pom.xml file in order to establish a custom plugin group in Maven. For example, to create the group com.example.plugins , you would put it in the groupId> element as follows:

<groupId>com.example.plugins</groupId> 

Now, when you build and install your plugin, it will belong to the com.example.plugins group and can be referenced using this group identifier. You can then use the <pluginGroup> element in your settings.xml file to add your custom plugin group to the list of plugin groups that Maven searches when resolving plugin references

For example:

<pluginGroups> 
  <pluginGroup>com.example.plugins</pluginGroup> 
</pluginGroups> 

This will allow you to use short plugin identifiers (e.g., my_plugin instead of com.example.plugins:my_plugin) when specifying plugins in your pom.xml file

To set up Maven to use multiple local repository directories, you'll need to add them to the <localRepository> element in the settings.xml file found in the .m2 folder. A comma can separate these directories. Maven will then search these directories for artifacts when resolving dependencies.  

You can specify multiple local repository directories using the -Dmaven.repo.local command line option when running Maven goals. Just pass a comma-separated list of directories as the value for this option. Once you've done this, Maven will search for artifacts in the multiple local repository directories you've specified. 

One of the most frequently posed Maven Interview Questions, be ready for it. To implement a custom Maven extension, you'll first need to create a Java class that implements the AbstractMavenLifecycleParticipant interface and overrides the afterProjectsRead method. This method will be called after Maven reads the project's pom.xml file and allows you to perform custom actions. You'll also need to create a plexus.component descriptor in the src/main/resources/META-INF/plexus/components.xml file. This descriptor will be used to register your extension with the Plexus container, the dependency injection container used by Maven.  

Finally, you'll need to package your extension as a JAR and install it in your local Maven repository by running the mvn install command. Once installed, you can use your extension by specifying it in the <build> section of the pom.xml file. That's it! Your custom Maven extension should now be up and running. 

To implement a custom Maven report, you'll need to create a Java class that extends the AbstractMavenReport class and overrides the generate method. This method will be called when the report is executed and allows you to generate the report. You'll also need to create a plexus.component descriptor in the src/main/resources/META-INF/plexus/components.xml file. This descriptor will be used to register your report with the Plexus container, the dependency injection container used by Maven. You'll also need to create a site.xml file in the src/site directory and add a <menu> element that references your report.  

Finally, you'll need to package your report as a JAR and install it in your local Maven repository by running the mvn install command. Once installed, you can use your report by specifying it in the <reporting> section of the pom.xml file. That's it! Your custom Maven report should now be up and running. 

To implement a custom Maven plugin repository, you'll need to create a settings.xml file in your .m2 directory and add a <pluginRepositories> element. You can then specify your custom plugin repository using the <repository> element and setting the <id>, <url>, and <layout> elements. The <id> element is used to identify the repository and should be unique. The <url> element specifies the URL of the repository, and the <layout> element specifies the layout of the repository.  

You can also specify the <snapshots> and <releases> elements to enable or disable the use of snapshot or released versions of plugins in the repository. Once you've done this, you'll need to install your plugin in the repository by running the mvn install command. Once installed, you can use your plugin by specifying it in the <build> section of the pom.xml file.  

To customize the Maven toolchain, you'll need to create a toolchains.xml file in your .m2 directory and add a <toolchain> element. You can then specify the tools in the toolchain using the <type>, <provides>, and <configuration> elements. The <type> element specifies the type of tools, such as JDK or compiler, and the <provides> element specifies the version of the tool. The <configuration> element allows you to specify the configuration for the tool, such as the path to the tool executable.  

You can also specify the <required> element to specify whether the tool is required for the build to succeed. Once you've done this, you can use your custom toolchain by specifying it in the <build> section of the pom.xml file using the <toolchain> element.  

To configure Maven to use a custom version of the Java compiler, you'll need to create a toolchains.xml file in your .m2 directory and add a <toolchain> element to it. You'll then need to specify the <type> of the tool as JDK and the <provides> element with the version of the Java compiler you want to use.  

You can also specify the <configuration> element to specify the path to the compiler executable. Once you've done this, you can use your custom Java compiler by specifying it in the <build> section of the pom.xml file using the <toolchain> element.

To configure Maven to use a custom version of the Java runtime, you'll need to create a toolchains.xml file in your .m2 directory and add a <toolchain> element to it. This file allows you to specify custom tools and configurations Maven should use when building your project. 

Within the <toolchain> element, you'll need to specify the <type> of the tool as JDK and the <provides> element with the version of the Java runtime you want to use. You can specify the <configuration> element to specify the path to the Java executable. 

Once you've done this, you can use your custom Java runtime by specifying it in the <build> section of the pom.xml file using the <toolchain> element. Maven will then use the tools and configurations specified in the toolchains.xml file when building your project. 

It's important to note that the toolchains.xml file is optional and is not automatically created for you. You'll need to create it yourself if you want to use custom tools or configurations. Additionally, the toolchains.xml file is only used when the maven-toolchain-plugin is specified in the pom.xml file. This plugin is responsible for binding the custom toolchain to the build. 

To set the source and target versions for the Maven compiler plugin, you'll need to add the plugin to your pom.xml file's <build> section and include the <source> and <target> elements. The <source> element determines the version of Java that your source code is written in, while the <target> element sets the version that the compiled code should be compatible with. As an example, to specify that your source code is written in Java 8 and the compiled code should be compatible with Java 11, you can include the following in your pom.xml file: 

<build> 
  <plugins> 
    <plugin> 
      <groupId>org.apache. Maven.plugins</groupId> 
      <artifactId>maven-compiler-plugin</artifactId> 
      <version>3.8.0</version> 
      <configuration> 
        <source>1.8</source> 
        <target>11</target> 
      </configuration> 
    </plugin> 
  </plugins> 
</build> 

It's important to note that the Maven compiler plugin is automatically included in the build section of the pom.xml file when you create a new Maven project using the archetype: generate a goal. However, the default source and target version are set to 1.5, so you'll need to update it if you want to use a different version. 

To customize the Maven compiler plugin's encoding, you'll need to add the maven-compiler-plugin to the <build> section of your pom.xml file and specify the <encoding> element. The <encoding> element specifies the character encoding of the source code that the compiler should use. 

For example, to specify that the compiler should use the UTF-8 character encoding, you would add the following to your pom.xml file: 

<build> 
  <plugins> 
    <plugin> 
      <groupId>org.apache. Maven.plugins</groupId> 
      <artifactId>maven-compiler-plugin</artifactId> 
      <version>3.8.0</version> 
      <configuration> 
        <encoding>UTF-8</encoding> 
      </configuration> 
    </plugin> 
  </plugins> 
</build> 

It's important to note that the Maven compiler plugin is automatically included in the build section of the pom.xml file when you create a new Maven project using the archetype: generate  a goal. However, the default encoding is set to UTF-8, so you'll only need to specify the <encoding>` element if you want to use a different character encoding. 

To configure Maven to use a custom version of the Maven plugin API, you'll need to add the maven-API-dep-plugin to the <build> section of your pom.xml file and specify the <version> element. The <version> element specifies the version of the Maven plugin API that you want to use. 

For example, to specify that you want to use version 3.7.0 of the Maven plugin API, you would add the following to your pom.xml file: 

<build> 
  <plugins> 
    <plugin> 
      <groupId>org.apache. Maven.plugins</groupId> 
      <artifactId>maven-api-dep-plugin</artifactId> 
      <version>3.7.0</version> 
    </plugin> 
  </plugins> 
</build> 

It's important to note that the Maven plugin API is used by Maven plugins to interact with the Maven runtime and is not automatically included in your project. If you want to use a custom version, you'll need to add it yourself. 

To configure Maven to use a custom version of the Maven core, you'll need to update the maven-core dependency in the <dependencies> section of your pom.xml file. The Maven core is the foundation of the Maven build system and is responsible for executing build goals and managing dependencies. 

For example, to specify that you want to use version 3.8.0 of the Maven core, you would add the following to your pom.xml file: 

<dependencies> 
  <dependency> 
    <groupId>org.apache.maven</groupId> 
    <artifactId>maven-core</artifactId> 
    <version>3.8.0</version> 
  </dependency> 
</dependencies> 

It's important to note that the Maven core is automatically included as a dependency in your project when you create a new Maven project using the archetype:generate a goal. However, the default version is set to the latest stable release at the time the project was created. You'll need to update the maven-core dependency if you want to use a different version. 

To configure Maven to use a custom version of the Maven model, you'll need to update the maven-model dependency in the <dependencies> section of your pom.xml file. The Maven model is a set of Java interfaces and classes that represent the fundamental pieces of a Maven build, such as the pom.xml file and the various build components and plugins. 

For example, to specify that you want to use version 3.8.0 of the Maven model, you would add the following to your pom.xml file: 

<dependencies> 
  <dependency> 
    <groupId>org.apache.maven</groupId> 
    <artifactId>maven-model</artifactId> 
    <version>3.8.0</version> 
  </dependency> 
</dependencies> 

It's important to note that the Maven model is automatically included as a dependency in your project when you create a new Maven project using the archetype:generate a goal. However, the default version is set to the latest stable release at the time the project was created. You'll need to update the maven-model dependency if you want to use a different version. 

To customize the version of the Maven settings model that Maven uses, you'll need to update the maven-settings dependency in your pom.xml file's <dependencies> section. The Maven settings model includes the interfaces and classes that represent the configuration for Maven, including the settings.xml file and the various profiles and active profiles. As an example, to specify version 3.8.0 of the Maven settings model, you can include the following in your pom.xml file: 

<dependencies> 
  <dependency> 
    <groupId>org.apache.maven</groupId> 
    <artifactId>maven-settings</artifactId> 
    <version>3.8.0</version> 
  </dependency> 
</dependencies> 

It's important to note that the Maven settings model is automatically included as a dependency in your project when you create a new Maven project using the archetype:generate a goal. However, the default version is set to the latest stable release at the time the project was created. You'll need to update the maven-settings dependency if you want to use a different version.

To customize the version of the Maven model builder that Maven uses, you'll need to update the maven-model-builder dependency in your pom.xml file's <dependencies> section. The Maven model builder is responsible for creating the in-memory version of the Maven model from the pom.xml file. To specify version 3.8.0 of the Maven model builder, you can include the following in your pom.xml file:  

<dependencies> 
  <dependency> 
    <groupId>org.apache.maven</groupId> 
    <artifactId>maven-model-builder</artifactId> 
    <version>3.8.0</version> 
  </dependency> 
</dependencies> 

It's important to note that the Maven model builder is automatically included as a dependency in your project when you create a new Maven project using the archetype:generate a goal. However, the default version is set to the latest stable release at the time the project was created. If you're preparing for a Maven interview and want to answer questions about customizing the Maven model builder, make sure to mention that you'll need to update the maven-model-builder dependency in the <dependencies> section of your pom.xml file to use a different version. 

To customize the version of the Maven artifact model that Maven uses, you'll need to update the maven-artifact dependency in your pom.xml file's <dependencies> section. The Maven artifact model includes the interfaces and classes that represent Maven artifacts like a jar, war, and ear files. To specify version 3.8.0 of the Maven artifact model, you can include the following in your pom.xml file: 

<dependencies> 
  <dependency> 
    <groupId>org.apache.maven</groupId> 
    <artifactId>maven-artifact</artifactId> 
    <version>3.8.0</version> 
  </dependency> 
</dependencies> 

It's important to note that the Maven artifact model is automatically included as a dependency in your project when you create a new Maven project using the archetype:generate goal. However, the default version is set to the latest stable release at the time the project was created. You'll need to update the maven-artifact dependency if you want to use a different version.