The introduction

Maven is the only automated build tool maintained by the Apache Software Foundation, focusing on project building and dependency management for the Java platform.

Start by asking yourself a few questions

Maven’s dependency finding order, scope, lifecycle, dependency rules, how to resolve dependency conflicts, and why not customize package versions. If you can answer this question, please give it a thumbup. 🤭

If you’re just being vague, check out the following article.

Dependent search order

Interviewer 👨 : Let’s warm up with a quick question. How does Maven find dependencies?

Xiao Ming 🤪 : first will go to the local warehouse looking for, and then will go to the company’s private service warehouse looking for, general private service warehouse is the company’s own development of jar packages, and finally will go to the Apache team to maintain the central warehouse looking for, once found in a place no longer looking for. Interviewer, make it harder. Too simple

Interviewer 👨 : Young man, very beautiful, then I ask you, our POM file has many tags, many students are confused about various tags and use, first to ask you the function of several common tags

Xiaoming 🤪 : Come on

How do I confirm the unique representation of this dependency

Interviewer 👨 : There are many dependencies in our project. How does the program locate this dependency?

Xiaoming 🤪 : That’s easy

Typically, we use the groupId, artifactId, and Version tags to identify the unique coordinates of this dependency

<groupId>: Enterprise website reverse + project name<artifactId>: Project name - Module name<version>: Current version<groupId>com.juejin.business</groupId>
<artifactId>juejin-image-web</artifactId>
<version>1.0.0 - the SNAPSHOT</version>

Copy the code

Scope Indicates the scope

Interviewer 👨 : The scope tag is often used in our projects. Do you know what the common scopes are?

Xiaoming 🤪 : I can’t do this

The scope we commonly use is

	compile	test	provided
The main program	Square root	x	Square root
The test program	Square root	Square root	Square root
Participate in the deployment	Square root	x	x

• Compile: The default range, which is valid for compiling, testing, and running
• Provided: Compile and test are valid, and the last run is not added, such as tomcat dependencies
• Runtime: valid at test and runtime, compilations are not added, such as the JDBC driver jar
• Test: Valid during the test phase, such as junit
• System: Consistent with provided, valid during compile and test phases, but associated with the system and poor portability
• Import: The scope of the import, which is used only in dependencyManagement to indicate the configuration of importing dependency from another POM

How are scope dependencies passed

Interviewer 👨 : Good answer. So if project A depends on the scope of Project B provided and project B depends on the scope of Project C Runtime, why does project A ultimately depend on the scope of project C?

Xiaoming 🤪 : Provided let me draw a picture for you

How to eliminate dependencies

Interviewer 👨 : After we introduced many dependencies, there was a high probability of dependency conflict. How did you solve it?

Xiao Ming 🤪 : Assuming that juejin-convert-web dependencies conflict, I would resolve this by first finding the conflicting project

1- Implemented with the Exclusions tag. When conflicting projects rely on juejin-image-Web projects, actively exclude the passed Juejin-convert-Web project dependencies

 <dependency>
        <groupId>com.juejin.business</groupId>
        <artifactId>juejin-image-web</artifactId>
        <version>1.0.0 - the SNAPSHOT</version>
        <exclusions>
            <exclusion>
                <groupId>com.juejin.business</groupId>
                <artifactId>juejin-convert-web</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
Copy the code

2- Implemented by optional

Modify the pom.xml of the juejin-image-Web project:

<dependency>
        <groupId>com.juejin.business</groupId>
        <artifactId>juejin-convert-web</artifactId>
        <version>1.0.0 - the SNAPSHOT</version>
        <optional>true</optional>
 </dependency>
Copy the code

Dependency transfer principle

Interviewer 👨 : You are familiar with Maven dependency delivery. Please elaborate on the principle of Maven dependency delivery.

Xiaoming 🤪 : Ok, Maven relies on two principles of passing. The first is the shortest path principle, and the second is the first declaration principle

Let me give you an example

– a – > b > c (2.0)

A – > c (1.0)

Finally take the C (1.0) version because it is short.

Let me give you an example of the second principle

– a – > b > c (2.0)

A – > d – > c (1.0)

C (2.0) is adopted because B first declares c.

Of course, if we rely on C directly in A, it must be based on the C version that our a project relies on, the next of kin principle

Maven’s life cycle

Interviewer 👨 : Maven has three separate life cycles: Clean Lifecycle, the core of a build, compile, test, package, install, deploy, and so on. Site Lifecycle generates project reports, sites, publish sites and you can also see that in the sidebar of IDEA

Can you expand on what these life cycles do?

Xiaoming 🤪 : Good

Clean Removes all files generated during the last build validate: verifies that the project is correct and all required resources are available. Compile: compile the project's source code. Test: Tests the compiled source code using an appropriate unit testing framework. These tests do not need to be packaged and deployed. Package: Packages compiled code into a releasable format, such as JAR, WAR, etc. Verify: Runs all checks to verify that the package is valid and meets quality standards. Install: Installs packages into maven's local repository, which can be used as dependencies by other projects to generate project site documentation. Deploy: Executes in an integration or publishing environment, copies the final version of the package to a remote repository, which can be shared by other developers or projectsCopy the code

Define any binary package version number in a subproject

Interviewer 👨 : One of our new interns randomly defined a version number of two-sided package in the sub-project. Do you think it is appropriate?

Xiao Ming 🤪 : Not suitable, because when we cooperate to develop the same application, if everyone randomly changes the version number of the two packages, then there will be conflicts when the branches merge, and the projects that reference the two packages will also conflict.

So the versioning of our packages is in the hands of the master POM, and it is forbidden to declare separate packages to be released or relied upon in subprojects

Interviewer 👨 : Not bad, young man come to work tomorrow

Xiaoming 🤪 : Ok

---

End of article, if this article has helped you, give it a like

If you want to know more about sharing, you can follow the official account

You can get interview questions/technical documents/e-books, etc

---

Phase to recommend

3 minutes to understand the bridge mode 11 exceptional best practices from Dachang Factory design patterns, do you know these issues?