Regarding issues related to Maven packaging

SpringBoot project regarding Maven packaging issues

All problems and solutions in this article are based on the IDEA development tool.

Maven packaging is missing resource files

There are three common reasons why this problem occurs:
First, the resources file in the project is not marked as the resource root directory.
Second, the pom file lacks the relevant configuration that specifies the configuration file path.
The third type is the issue of absolute paths and relative paths (emphasis).

The resources file in the project is not marked as the resource root directory

Let’s talk about the first situation first. Figure 1-1 shows that the resources file in the SpringBoot project is not marked as the resource root directory. At this time, the configuration file under the resources file will not take effect, that is, it will not be SpringBoot automatically scans it.

The solution is to right-click the resources file and select Mark Directory as -> Resources Root to mark the directory as the resource root directory. After marking, it will look like Figure 1 -2 same.
You can also open the project structure window through File->Porject Structure and select the Sources module of Modules to mark, such as Figure 1-3.
Figure 1-2

The pom file lacks the relevant configuration of the specified configuration file path

The reason for the second situation is related to the pom file. Through the above, we have marked resources as the resource root directory. If there are still problems with packaging resource files, you can add the following configuration to the pom file:

 <build>
        <resources>
            <resource>
                <directory>src/main/java</directory>
                <includes>
                    <include>**/*.xml</include>
                    <include>**/*.properties</include>
                </includes>
                <filtering>true</filtering>
            </resource>
            <resource>
                <directory>src/main/resources</directory>
                <includes>
                    <include>**/*.xml</include>
                    <include>**/*.properties</include>
                </includes>
                <filtering>true</filtering>
            </resource>
        </resources>
    </build>

But under normal circumstances, there will be no problem if you place the resource files in the default src/main/resources directory. Whether you need to write the above configuration depends on the following three situations:

Compilation and packaging: For compilation and packaging, by default, Maven will process all resource files in the src/main/resources directory. Therefore, if your resource files are all in this directory and you do not use the filtering function, then removing this configuration will probably not affect your project.
Resource filtering: However, if you use the resource filtering function (for example, use placeholders in the form of ${property} in the resource file and define the values of these properties in pom.xml ), then after removing this configuration, resource filtering will no longer occur, which may affect your project.
Non-default resource directory: If your resource files are not in the src/main/resources directory, or you have additional resource directories, then you need this configuration to specify these directories, otherwise Maven will not process files in these directories.

Absolute path and relative path issues

If the above configurations are all checked and there are still missing resource files when using Maven to package, it is most likely caused by the third reason. You can see the difference between them in Figure 1-4 and Figure 1-5. If your configuration is consistent with Figure 1-4, congratulations, you will find that when you use the Idea tool to start the project, target/classes directory, but once Maven is used for packaging, the resource files disappear. If your configuration is consistent with Figure 1-5, there will be no problem. This is caused by absolute paths and relative paths. The writing method in Figure 1-4 belongs to the absolute path, and the writing method in Figure 1-5 belongs to the relative path. Let’s talk about the difference between the above two ways of writing: For src/main/resources:



This is a relative path to the POM file, which points to the src/main/resources directory in the project. This is Maven's default resource directory and usually contains the application's configuration files, property files, etc.

For  /src/main/resources:

This is an absolute path starting from the root of the file system. It points to the /src/main/resources directory in the file system, not src/main/resources in the project directory.

Using the second way of writing (that is, the path starting from the root directory, such as /src/main/resources) may cause the following problems when packaging with Maven:

Path error: Since this is an absolute path starting from the root of the file system, if the POM file is not in the expected location, Maven may not be able to find the resource directory, causing the build to fail.
Non-portability: As with the previous example, using an absolute path will make your project less portable, as it may behave differently in different operating systems or file systems.
Default configuration override: Maven has a default resource directory configuration, which usually points to src/main/resources. If you use absolute paths, you may override these default configurations, causing confusion or unnecessary complexity.

Here is another addition to the difference between relative paths and absolute paths:


Start of path: A relative path is a path that starts from the location of the current file. It is a path relative to the current file. An absolute path, on the other hand, is a full path starting from the root directory of the file system and does not depend on the current file location.
Path representation: A relative path is represented by a path relative to the current file or directory, which is usually a path relative to the current working directory or the current file. A relative path is more concise because it only requires specifying the path from the current location to the target file. While an absolute path provides the complete path from the root directory to the target file, so it is usually longer.

The following are examples of relative and absolute paths:

Absolute path example: In a file system, an absolute path might look like C:\Users\Username\Documents\file.txt. On the web, an absolute path can be a full URL, such as http://www.example.com/path/to/file.html.
Relative path example: If the current file is file.txt, and there is a file named image.jpg in the same directory, then the relative path may be ./image.jpg. If image.jpg is in the upper directory, the relative path might be.../image.jpg.

SpringBoot introduces third-party jar package problem

Generally, SpringBoot projects use Mavne or Gradle tools for dependency management (here, Maven is used as the basis for demonstration), but there are also special cases where third-party dependencies that do not exist need to be used. At this time, a new one may be created in the resources directory of the project. The lib directory introduces third-party dependencies for management.
 But this method may extend to a problem, how to let Maven find them when we use Maven to package? Let’s find the answer to this question.

Point to third-party dependencies in the resources/lib directory through the pom file
If the project needs to use third-party dependencies that are not managed by Maven, put the dependencies into the resource/lib directory and add the following configuration to the pom file:
 <!-- You need to replace <groupId>, <artifactId> and <version> with the actual information of the third-party dependency. The <scope> element is set to system, indicating that this is a system-level dependency.
The <systemPath> element specifies the path of the dependent file, and ${project.basedir} represents the root directory of the project. -->
<dependency>
            <groupId>com.tpaic</groupId>
            <artifactId>auto-client</artifactId>
            <version>1.0</version>
            <scope>system</scope>
            <systemPath>${project.basedir}/src/main/resources/lib/auto-client.jar</systemPath>
        </dependency>

Figure 2-1 shows the location of third-party dependencies.
 
 After adding it according to the above steps, the dependency has been added to the project. However, when using Maven for packaging, you will find that the manually imported third-party dependencies are not packaged. If you run the packaged jar file at this time, an exception will definitely be thrown.
The solution is to add the following configuration to the pom file:
 <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <!-- Load all system dependencies -->
                    <includeSystemScope>true</includeSystemScope>
                </configuration>
            </plugin>
        </plugins>

trueThe key configuration is this code. After adding it and then packaging it, you will find that the third-party dependencies have been loaded. The  configuration is mainly used to determine whether system scope dependencies are included in certain Maven operations, such as creating WAR files or JAR files. When this configuration is set to true, system scope dependencies will be included; when set to false, they will not. In Maven, dependencies can have different scopes, such as compile, runtime, test, provided, system, etc. Each scope has different meaning and purpose. Among them, system scope dependencies are usually dependencies that you need to import from the local file system or other non-Maven repository locations.
Add third-party dependencies to the Maven repository through commands

First open the computer terminal
Enter the following command (provided that maven's environment variables have been configured):

mvn install:install-file -DgroupId=com.fjc -DartifactId=toolUtil -Dversion=1.0.1 -Dpackaging=jar -Dfile=D:\fanjunchao\ToolUtil.jar

Parameter Description:

-DgroupId: indicates the groupId corresponding to the jar
-DartifactId:: represents the artifactId corresponding to the jar
-Dversion:: Indicates the version corresponding to the jar
-Dfile: Indicates the location of the jar D:\fanjunchao\ToolUtil.jar

The following is the successful execution:
 
 Finally, just introduce our corresponding coordinates in pom.xml:

 <dependency>
            <groupId>com.fjc</groupId>
            <artifactId>toolUtil</artifactId>
            <version>1.0.1</version>
        </dependency>