Maven's primary goal is to build Java-based projects and manage project information and dependencies.
Constraints
- If you need to use a custom settings file for a Maven build, ensure it meets the following requirements:
- 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.
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 by referring to CodeArts User Guide > "Preparations" > "Creating Service Endpoints".
- Click Add, select the service endpoint created in the previous step, and select Release and Snapshot as required.
NOTE:
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:
- Use cloudbuild@maven3.5.3-jdk8-open. This address starts with cloudbuild and uses the at sign (@) as a separator, with the default image version provided by CodeArts Build following it.
- Use a complete SWR image path, for example, swr.example.example.com/codeci_test/demo:141d26c455abd6d7xxxxxxxxxxxxxxxxxxxx.
|
settings |
Map |
Optional. 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.
|
You can access the uploaded files in either of the two ways.
- On the CodeArts Build homepage, click More and select Files.
- Alternatively, click Manage Files in the Download File From File Manager action.
On the
Files page, you can edit, download, and delete files, as well as configure operation permissions for other users.
- Enter a keyword in the search box to search for a file.
- Click
in the Operation column to modify the file name and specify whether to allow all members of your account to use the file in CodeArts Build.
- Click
in the Operation column to download the file.
- Click
in the Operation column and select Delete from the drop-down list. Confirm the deletion as prompted.
- Click
in the Operation column and select Modify Permissions from the drop-down list. In the displayed dialog box, configure file operation permissions for the user.
By default, the creator has all permissions, which cannot be deleted or modified.
Figure 1 Configuring file operation permissions for a user
Table 4 Roles and their permissions on files
Permission |
Role with the Permission |
Add users |
All users in the project |
View a file |
File creator and users under the same account |
Use a file |
File creator and users with the use permissions configured by the file creator |
Update a file |
File creator and users with the update permissions configured by the file creator |
Delete a file |
File creator and users with the delete permissions configured by the file creator |
Modify permissions |
File creator |
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.
- 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 2.
Figure 2 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
The unit test coverage report distinguishes between the code that has been exercised through unit tests and those that have not been covered. It helps you understand whether your tests have checked all code paths and logic.
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> #It defines the target phase of the report.
<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>
|