Maven's primary goal is to build Java-based projects and manage project information and dependencies.
Tutorial Video
Learn to build with Maven on the GUI in this video tutorial.
Build on GUI
Add Build with Maven, when configuring build actions. Set the parameters according to Table 1.
Table 1 Parameters for building with Maven
|
Parameter |
Description |
|
Action Name |
Assign a custom name to the build action. The name can contain:
- Letters, digits, hyphens (-), underscores (_), commas (,), semicolons (;), colons (:), periods (.), slashes (/), and parentheses.
- 1 to 128 characters.
|
|
Tool Version |
Select a tool version that matches your current development environment.
For tool versions supported by CodeArts Build, see build tools and versions. If the current tools and versions do not meet your requirements, you can customize a build environment. |
|
Commands |
Configure the Maven commands, or use the default ones. For more commands, see the Maven official website. |
|
Continue After Failure |
Specify whether to proceed after the current action fails by setting the parameter to either Yes or No. |
|
setting File Configuration |
- Generate setting File with Repositories: The optimal repository access mode is automatically configured based on your IP address when you access the setting.xml file provided by CodeArts.
Your IP address may be in regions in or outside the current country. You are advised to retain the default settings.
The setting.xml file defines the default dependency pull sequence and mirror source proxy. If you need to use a custom setting.xml file, add a custom setting.xml file and add --settings settings.xml to the end of the default packaging command. Then, you can use the added settings.xml file to build with Maven.

- Public Repositories: By default, Huawei Mirrors is added, and Huawei SDK repositories has been configured. This configuration is used only when you need to add a public repository that is not provided by CodeArts. The procedure is as follows:
- Click Add.
- Enter the repository address, and select Release and Snapshot as required. Select either Release or Snapshot, or both.
Release: If this option is selected, the build process attempts to download the release version dependency from the repository.
Snapshot: If this option is selected, the build process attempts to download the snapshot version dependency from the repository.
- Private Repositories: Self-hosted repos provided by CodeArts have been configured by default. This configuration is used only when you need to add other private repository. The procedure is as follows:
- Create a Nexus repository service endpoint.
- Click Add, select the service endpoint created in the previous step, and select Release and Snapshot as required.
Release and Snapshot are two types of repositories. Pay attention to their differences. If you upload a dependency to a release repository, it cannot be downloaded during a build.
- Snapshot: For private dependency packages released for debugging, add the -SNAPSHOT suffix to the dependency version (for example, 1.0.0-SNAPSHOT). During each release, the dependency is automatically released to the snapshot repository. The version does not need to be updated each time the dependency is released. You can add the -U parameter to the build command to obtain the latest version.
- For officially released private dependency packages, do not add the -SNAPSHOT suffix to the dependency version (for example, 1.0.0). During each release, the dependency is automatically released to the release repository. The version must be updated each time the dependency is released. Otherwise, the latest dependency package cannot be obtained during the build.
|
|
Release to Self-hosted Repos |
By default, CodeArts Build uses the self-hosted repos as the download source of private dependency. The configuration is required for uploading build products to the self-hosted repos and store the build products as dependencies for other projects. Before the configuration, create a self-hosted repo. The configuration procedure is as follows:
- Do not configure POM: Private dependencies do not need to be released to the self-hosted repo of CodeArts Artifact.
- Configure all POMs: Deployment configurations are added to all pom.xml files of the project. The mvn deploy command is used to upload the built dependency package to a self-hosted repo.
In the command window, use the number sign (#) to comment out the mvn package -Dmaven.test.skip=true -U -e -X -B command, as shown in the following figure.

Delete the number sign (#) before the #mvn deploy -Dmaven.test.skip=true -U -e -X -B command, as shown in the following figure.

The uploaded private dependency can be referenced by adding the groupId, artifactId, and version coordinates in the pom.xml file to other projects. |
|
Unit Test |
To process unit test results, set the parameters. For details, see Configuring a Unit Test. |
|
Cache |
Opt to use the cache to improve the build speed. If you set Use Dependency Cache to Yes, the downloaded dependency package is cached during each build. In this way, the dependency package does not need to be pulled repeatedly during subsequent builds, which effectively improves the build speed.
The dependency cache files of a Maven build task cannot be updated. The cache directory will be updated only when new dependencies are imported to the task. |
Build with Code
Modify the code in the BUILD block in Creating a YAML File for Your Code-based Build by referring to the following sample code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
version: 2.0 # The value must be 2.0.
steps:
BUILD:
- maven:
image: cloudbuild@maven3.5.3-jdk8-open
inputs:
settings:
public_repos:
- https://mirrors.example.com/maven
cache: true # Determine whether to enable caching.
unit_test:
coverage: true
ignore_errors: false
report_path: "**/TEST*.xml"
enable: true
coverage_report_path: "**/site/jacoco"
command: mvn package -Dmaven.test.failure.ignore=true -U -e -X -B
ignore_fail: true
|
Table 2 Parameters in the sample code
|
Parameter |
Type |
Description |
|
image |
String |
The image address can be in either of the following formats:
|
|
settings |
Map |
Optional. Set this parameter if you need a custom settings.xml file.
If this parameter is not set, the setting.xml file provided by CodeArts is used by default. If you need to use a custom settings.xml file, add a custom setting.xml file and add --settings settings.xml to the end of the default packaging command mvn package -Dmaven.test.failure.ignore=true -U -e -X -B. |
|
cache |
Bool |
Optional.
Specify whether to enable cache.
- true: Enable.
- false: Disable.
The default value is false. |
|
command |
String |
Configure the Maven command. For more commands, see the Maven official website. |
|
unit_test |
Map |
Optional.
Configure the unit test. For details, see Configuring a Unit Test. |
|
ignore_fail |
String |
Whether to proceed after the current action fails.
|
Adding a Custom setting.xml File
The file restrictions are as follows:
- The maximum file size is 100 KB.
- The file type must be .xml, .key, .keystore, .jks, .crt, or .pem.
- A maximum of 20 files can be uploaded.
You can add files in either of the following ways:
- Build on GUI
- In the Commands window of the Build with Maven action, run the cat /home/build/.m2/settings.xml command. After the task is complete, the content of the settings.xml file will be displayed in the build logs.
- Customize a new settings.xml file according to the settings.xml file's information displayed in the build logs.
- Add the Download File from File Manager action before the Build with Maven action.
Assign a custom name to the action and select a tool version. Currently, only shell4.2.46-git1.8.3-zip6.00 is supported.
- Click Upload. In the displayed dialog box, select the file created in 2, add a description, select the agreements, and click Save.
- Expand the File Name drop-down list and select the uploaded setting.xml file.
- Build with Code
Modify the code in the
BUILD block in
Creating a YAML File for Your Code-based Build by referring to the following sample code:
|
|
version: 2.0 # The value must be 2.0.
steps:
BUILD:
- download_file:
inputs:
name: settings.xml
ignore_fail: true
|
Table 3 Parameters in the sample code for downloading a file
|
Parameter |
Type |
Description |
|
name |
String |
Name of the setting file. |
|
ignore_fail |
String |
Whether to proceed after the current action fails.
|
Other Operations
Configuring a Unit Test and Generating a Unit Test Coverage Report Using JaCoCo are optional. Configure them if needed.
- Configuring a unit test: The Maven build action leverages unit tests to ensure that your code's core functions operate as expected. Within a Maven project, testing frameworks like JUnit are used to write and execute these tests.
- Generating a unit test coverage report using JaCoCo: The unit test coverage report distinguishes between the code that has been examined through unit tests and those that have not been covered. It helps you understand whether your tests have checked all code paths and logic.
Configuring a Unit Test
- Before configuring a unit test, you need to write unit test code in the project and ensure that the following conditions are met:
- Create a unit test class in the code repository, as shown in Figure 1.
Figure 1 Unit test file directory
The following sample code is from the Demo.java file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
package test;
public class Demo {
public String test(Integer i) {
switch (i) {
case 1:
return "1";
case 2:
return "2";
default:
return "0";
}
}
}
|
The following sample code is from the DemoTest.java file:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
package test;
import org.junit.Test;
public class DemoTest {
private Demo demo=new Demo();
@Test
public void test(){
assert demo.test(1).equals("1");
assert demo.test(2).equals("2");
assert demo.test(3).equals("0");
}
}
|
- Configure a unit test in the build action.
- Once the task is successfully completed, you can access the test report on the testing tab of the task execution details page. When you opt to print the unit test coverage report, a report is generated. You can download it by clicking the button for downloading the test coverage report.
Generating a Unit Test Coverage Report Using JaCoCo
If you set Print Unit Test Results to Yes, complete configurations as follows:
- Configuration method for a single-module project
To generate the unit coverage report, add jacoco-maven-plugin to the project by including the following configuration to the pom.xml file.
By default, the JaCoCo report goal is bound to the verify phase. You need to change the report goal to the test phase.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.5</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
|
- Configuration method for a multi-module project
Assume that the code structure of a multi-module project looks like the following example. You will walk through how to configure and generate a unit test report.
|
|
├── module1
│ └── pom.xml
├── module2
│ └── pom.xml
├── module3
│ └── pom.xml
├── pom.xml
|
- Add an aggregation module named report to the project. Your code directory structure then looks like this:
|
|
├── module1
│ └── pom.xml
├── module2
│ └── pom.xml
├── module3
│ └── pom.xml
├── report
│ └── pom.xml
├── pom.xml
|
- Add jacoco-maven-plugin to the pom.xml file in the root directory of the project. The following is a code sample:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<!-- Configure unit test coverage-->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.3</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
</plugin>
|
- Configure the pom.xml file of the aggregation module.
Use dependency elements to introduce all dependency modules and use report-aggregate to define the JaCoCo aggregation goal.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>module1</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>module2</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>module3</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.3</version>
<executions>
<execution>
<id>report-aggregate</id>
<phase>test</phase>
<goals>
<goal>report-aggregate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
|
- Once the configuration is completed, run mvn test in the root directory of the project. After the command is successfully executed, the coverage report of each module is generated in the report/target/site/jacoco-aggregate directory. You can also customize an output path for the reports by configuring outputDirectory.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.3</version>
<executions>
<execution>
<id>report-aggregate</id>
<phase>test</phase>
<goals>
<goal>report-aggregate</goal>
</goals>
<configuration>
<outputDirectory>target/site/jacoco</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
|