The introduction

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

Let’s start by asking ourselves some questions

Maven’s dependency finding order, scope scope, life cycle, dependency principles, how to resolve dependency conflicts, why not customize the version number of the two-sided package. If you can answer this question successfully, then give a “like” before you go out. 🤭

If you’re just being vague, take a look at the following article.

Dependence finding order

Interviewer 👨 : To warm up, how does Maven find dependence?

Xiaoming 🤪 : first to the local warehouse to look for, and then to the company’s private server warehouse to look for, the general private server warehouse is the company’s own development of the JAR package, finally will go to the Apache team to maintain the central warehouse to look for, once found in a place will no longer look for. Interviewer, make it harder. Too simple

Interviewers 👨 : young man, very floating ah, then I ask you, our POM file has a lot of labels, many students on a variety of labels and use confused, to ask you the role of a few common labels

Xiao Ming 🤪 : let the horse come

How do I verify a unique representation of this dependency

Interviewer 👨 : In our project, there are so many dependencies. How does the program locate these dependencies?

Xiaoming 🤪 : This is easy

Typically, we use the groupId, artifactID, version tags to confirm the unique coordinates of this dependency

<groupId> : enterprise url reverse + project name <artifactId> : project name - module name <version> : < grouppid >com.juejin.business</ grouppid > <artifactId>juejin-image-web</artifactId> <version>1.0.0-SNAPSHOT</version>

What scope is there

Interviewee 👨 : Scope tags are often used in our projects. Do you know what common scopes are?

Xiaoming 🤪 : this can’t beat me

The scope of our common scope 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: Default range, valid for compile, test and run
  • Provided: Provided: compilations and tests are valid, and the final 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: The test phase is valid, such as JUnit
  • System: Provided as provided, provided that the compile and test phase is valid, but is related to the system, portability is poor
  • Import: The scope of the import, which is only used in DependencyManagement to represent a configuration that imports dependency from another POM

How are dependencies of Scope passed

Interviewers 👨 : Good answer, so if project A depends on project B provided and project B depends on project C provided, what is the final project A dependent on project C?

Xiaoming 🤪 Depend on Provided Let me draw a picture to show you

How to exclude dependencies

Interviewer 👨 : After we introduce a lot of dependencies, there is a high probability of dependency conflict. How do you resolve it?

Xiao Ming 🤪 : If there is a conflict between the juejin-convert-web dependency, I will solve it like this. First, I will find the conflict project

1- This is achieved by the Ex-Inclusion tag. When a conflicting project depends on a juejin-image-web project, proactively exclude the passed juejin-convert-web project dependency

<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>

2- Implemented through 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 >

Principle of dependency transfer

Interviewer 👨 : You have a certain understanding of Maven dependency transfer. Please elaborate on the principle of Maven dependency transfer.

Xiao Ming 🤪 : OK, there are two principles of Maven dependency transfer, the first one is the shortest path principle, the second one 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.

Here is another example to illustrate the second principle

– a – > b > c (2.0)

A – > d – > c (1.0)

Since B claims to introduce C first, C (2.0) is taken.

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

The Maven lifecycle

Interviewers 👨 : Maven has three separate lifecycles: Clean Lifecycle does some cleanup before the actual build, Default Lifecycle the core part of the build, compile, test, package, install, deploy, etc. Site Lifecycle generates project reports, sites, distribution sites and you can also see it in the SIDEB of IDEA

You expand on what these life cycles do?

Xiao Ming 🤪 : Good

Clean removes all files generated from the last build validate: validate that the project is correct and all required resources are available compile: project source code test: use the appropriate unit test framework to test compiled source code. These tests do not need to be packaged and deployed. Package: Package compiled code into a releasable format, such as JAR, WAR, and so on. Verify: Run all checks to verify that the package is valid and meets quality standards. Install: Install the package to Maven's local repository, which can be used by other projects as a dependency to generate the project's site document deploy: execute in integration or release environment, copy the final version of the package to a remote repository, so that other developers or projects can share the final version

Optionally define a two-pack version number in a subproject

Interviewers 👨 : One of our new interns arbitrarily defined a version number of a two-sided package in a subproject. Do you think it is appropriate?

Xiaoming 🤪 : Not appropriate, because when we collaborate to develop the same application, if everyone arbitrarily modify the version number of the two-party package, then there will be conflicts when the branch merge, and the project referring to the two-party package will also be conflicted.

So our package versioning is in the hands of the master POM, prohibiting separate declarations of two-party packages to be released or relied on in subprojects

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

Xiao Ming 🤪 : OK

This is the end of the article. If this article has helped you, please give it a like

To learn more about sharing, you can pay attention to the public number

Public number reply “information” can obtain big factory interview questions/technical documents/e-books and so on