Package or Symbol Not Found

Symptoms

When Maven build task is executed, an error message is displayed, indicating that the package or symbol cannot be found. For example:

com/xxx/xxx/configserver/encryptor/xxx.java:[11,40] package com.sun.jersey.api.client.config does not exist

Cause Analysis

According to the log, the project references the com.sun.jersey.api.client.config package. However, the package cannot be found in the project or all parsed dependency packages. The problem lies either in the code or the environment/component:

• Code problem: The package reference in the code is incorrect. In this case, check the code to solve the problem.
• Environment/Component problems: The dependency package is damaged or inconsistent. This type of problem is usually accompanied by successful native compilation with failed build in the cloud. The following sections provide solutions to solve different types of environment or component problems:
  • Dependency package conflict
  • Incorrect dependency scope
  • Dependency package uploaded using the groupId, artifactId, and version (GAV)
  • Damaged dependency package
  • Others

Dependency Package Conflict

Sometimes, multiple versions of the same artifact exist in a project due to misoperation or third-party dependency imports. This will make the used version different from the required version, and as a result the specified package cannot be found. To solve this problem, perform the following steps:

1. Use either of the following methods to check the version of the dependency package:
   1. Maven resolves dependency conflicts with the following strategies:
      • Nearest wins: For example, when building A, two dependencies exist: A > B > C > X 1.0 and A > D > X 2.0. Then X 2.0 will be used because the path from A to X through D is shorter.
      • First declaration wins: If two dependency versions are at the same depth, the first declaration wins.

   2. Use the Maven Dependency Plugin and run the mvn dependency:tree command in the build task.

2. If the build fails because the artifact version is not the required version, import the required dependency at the outermost layer of the POM and try again.

   <dependencys>
   	<dependency>
   		<groupId></groupId>
   		<artifactId></artifactId>
   		<version></version>
   	</dependency>
   </dependencys>

Incorrect Dependency Range

In Maven, the dependency scope attribute specifies the visibility of a dependency. If the dependency scope is incorrectly specified, the dependency will be invalid during compilation. If the package in the dependency is used in the main code of the project, a compilation error will occur. Perform the following steps to solve the problem.

1. Run the mvn dependency:tree command to view the dependency and dependency scope used by the project.
2. Compare the dependency scope and the location where the dependency is used in the project.

   If the package in the dependency is used in the main code and the dependency must be valid during builds, the dependency scope must be one of the following options:

   • compile
   • provided
   • system: The location of the dependency file is specified in systemPath. The package must exist in the specified directory.

Dependency Package Uploaded Using the groupId, artifactId, and version (GAV)

• When uploading a dependency package to self-hosted repos using the GAV, you only need to upload the JAR package. The POM file will be generated automatically, but only contains the identifiers of the dependency. The original <dependencies> details will be lost.
• For example, assume that you use artifact A, which is built through project A, for building project D. Artifact A contains a third-party tool, B. The dependency relationships are: D > A > B. When parsing artifact A, Maven will not be able to identify artifact B. As a result, project D cannot find contents in artifact B. In this case, perform the following steps:

1. Check the dependency tree of project D and check whether the missing content is introduced by the POM file of project A. If yes, go to the next step. If no, try other solutions.
2. Download the POM file of artifact A from CodeArts Artifact and compare it with the POM file of project A. If the downloaded file does not contain the content introduced by B, go to the next step. Otherwise, try other solutions.
3. Update the version of artifact A and upload it again using either of the following methods:
   • Build project A in CodeArts Build. Run the deploy command to upload artifact A to the private Maven repository. You can use the pipeline for automation.
   • Upload artifact A to the private Maven repository again. This time, upload the JAR packages and POM files separately.

4. Build project D again.

Damaged Dependency Package

If the dependency package is damaged, some files in the package may be missing. As a result, the required dependency package can be found during a build, but the CLASS file or package cannot be found. The solution varies by the package type:

• Third-party dependency package: Contact technical support.
• Self-developed package (manually uploaded to the private Maven repository): Perform the following procedure.
  1. Download the dependency package from the private Maven repository.
  2. Decompress the package and check whether the content is normal.
  3. If the content of the dependency package is abnormal, perform either of the following steps:
     • If the package is provided by a third party and manually uploaded to the private Maven repository, ensure that the package file is correct and upload the package again. (Note that both the POM and JAR files must be uploaded.)
     • If the dependency package is built by yourself (on premises or in the cloud) and the code is correct, check whether the JAR package is incomplete because multiple build tasks run in parallel.