Table of contents
4.2.1 Dependency is transitive
1. What is Maven
Maven is an open source project under Apache and a tool for managing and building java projects.
Official website: Maven – Welcome to Apache Maven
https://maven.apache.org/ The Apache Software Foundation, established in July 1999, is currently the world's largest and most popular open source software foundation, and is also a dedicated support A non-profit organization born out of open source projects.
2. The role of Maven
What can you do with Maven?
dependency management
Unified project structure
project build
Dependency management:
When using maven for project dependency (jar package) management, it is very convenient to solve this problem. We only need to add a configuration as shown in the figure below in the pom.xml file of the maven project.
Unified project structure:
If we create a maven project, it can help us automatically generate a unified and standard project directory structure:
Project build:
Maven provides a standard, cross-platform (Linux, Windows, MacOS) automated project construction method
3. Overview of Maven
3.1 Introduction to Maven
Apache Maven is a project management and construction tool, which is based on the concept of the Project Object Model (Project Object Model, referred to as: POM), and manages the construction, reporting and documentation of the project through a small piece of description information.
The role of Maven:
Convenient dependency management
Unified project structure
Standard project build process
3.2 Maven model
Project Object Model
Dependency Management Model (Dependency)
Build lifecycle & phases
Build lifecycle & phases
The part framed in purple in the above figure is used to complete the standardized construction process. When we need to compile, Maven provides a compilation plugin for us to use; when we need to package, Maven provides a packaging plugin for us to use, etc.
Project Object Model
The part framed in purple in the above figure belongs to the project object model, which is to abstract our own project into an object model with its own exclusive coordinates
Dependency Management Model (Dependency)
The part framed in purple in the above figure belongs to the dependency management model, which uses coordinates to describe which third-party jar packages the current project depends on
When we needed a jar package in our project before, we directly copied the jar package to the lib directory under the project, but now how can we find the desired jar package file with the coordinates written in the pom.xml file?
Answer: Maven repository
3.3 Maven repository
Warehouse: used to store resources and manage various jar packages
The essence of a warehouse is a directory (folder), which is used to store all dependencies (that is, jar packages) and plug-ins in development
The Maven warehouse is divided into:
Local warehouse: a directory on your own computer (used to store jar packages)
Central warehouse: the only one in the world maintained by the Maven team. Warehouse address: Central Repository:
Remote warehouse (private server): generally a private warehouse built by a company team
When the coordinates are used in the project to import the corresponding dependent jar package, it will first check whether there is a corresponding jar package in the local warehouse
If there is, it is directly referenced in the project
If not, go to the central warehouse to download the corresponding jar package to the local warehouse
If you can also build a remote warehouse (private server), the search order of the jar package in the future will become: local warehouse --> remote warehouse --> central warehouse
4. Dependency management
4.1 Dependency configuration
Dependency: Refers to the jar packages required for the current project to run. Multiple dependencies can be introduced into a project:
For example: In the current project, we need to use logback to record logs. At this time, we can introduce the dependency of logback in the pom.xml file of the maven project. Specific steps are as follows:
Write the <dependencies> tag in pom.xml
Use <dependency> in the <dependencies> tag to introduce coordinates
Define the groupId, artifactId, version of the coordinates
<dependencies> <!-- 第1个依赖 : logback --> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.11</version> </dependency> <!-- 第2个依赖 : junit --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> </dependencies>Click the refresh button to import the newly added coordinates
Refresh dependencies: ensure that the latest coordinates can be added every time a new dependency is introduced or an existing dependency configuration is modifiedPrecautions:
If the imported dependency does not exist in the local warehouse, it will connect to the remote warehouse/central warehouse, and then download the dependencies (this process will be time-consuming, please wait patiently)
If you do not know the dependent coordinate information, you can search in mvn's central warehouse ( https://mvnrepository.com/ )
Several ways to add dependencies:
Leverage dependent coordinates for central repository search
Use IDEA tools to search for dependencies
After getting used to maven proficiently, quickly import dependencies
4.2 Dependency delivery
4.2.1 Dependency is transitive
When we didn't use maven in the early days, adding dependent jar packages to the project required copying all the jar packages to the project project. As shown in the figure below, when logback-classic is required, since logback-classic depends on logback-core and slf4j, all three jar packages must be copied to the project project
We are using maven now. When you need to use logback-classic in the project, you only need to add the dependency coordinates of logback-classic in the pom.xml configuration file.
Only the logback-classic dependency is added in the pom.xml file, but because maven's dependency is transitive, it will automatically import other dependent jar packages.
Dependency transfer can be divided into:
Direct dependencies: dependencies established through dependency configuration in the current project
Indirect dependency: If the dependent resource depends on other resources, the current project indirectly depends on other resources
projectA depends on projectB. For projectA, projectB is a direct dependency.
And projectB depends on projectC and other jar packages. Then at this time, the dependencies of projectC will also be passed down in projectA. For projectA, projectC is an indirect dependency.
4.2.2 Excluding dependencies
Question: Earlier we said that dependencies are transitive. Then A depends on B, and B depends on C. If A does not want to depend on C, can it be done?
Answer: In a maven project, we can do this by excluding dependencies.
What is an exclusion dependency?
Exclude dependencies: Refers to actively disconnecting dependent resources. (Excluded resources do not need to specify a version)
<dependency> <groupId>com.itheima</groupId> <artifactId>maven-projectB</artifactId> <version>1.0-SNAPSHOT</version> <!--排除依赖, 主动断开依赖的资源--> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> </exclusions> </dependency>
4.3 Dependency scope
After importing the dependent jar package in the project, it can be used anywhere by default.
If you want to limit the scope of use of dependencies, you can set its scope through the <scope> tag.
Scope of action:
The scope of the main program is valid (in the scope of the main folder)
The test program scope is valid (within the scope of the test folder)
Whether to participate in package operation (in the scope of package instruction)
Specify the scope of the dependency for the junit dependency through the scope tag. Then this dependency can only be used in the test environment, and cannot be used in other environments.
The value range of the scope tag:
4.4 Life cycle
4.4.1 Introduction
Maven's life cycle is to abstract and unify all construction processes. Describes a project construction, which stages it goes through.
Before the emergence of Maven, the life cycle of project construction already existed, and software developers cleaned, compiled, tested and deployed projects every day. Although everyone is doing construction work non-stop, companies and companies, projects and projects often use different methods to do similar work.
Maven learns and reflects from a large number of projects and construction tools, and then summarizes a set of highly perfect and easy-to-extend project construction life cycles. This life cycle includes cleanup, initialization, compilation, testing, packaging, integration testing, verification, deployment and site generation of the project and almost all construction steps.
Maven divides the life cycle of project construction into 3 sets (independent of each other):
clean: Clean up work.
default: core job. Such as: compilation, testing, packaging, installation, deployment, etc.
site: Generate reports, publish sites, etc.
We have seen these three sets of life cycles, there are many, many stages in them, so many life cycle stages, in fact, we do not use many commonly used, mainly focus on the following:
• clean: remove files generated by the previous build
• compile: Compile the project source code
• test: run tests using a suitable unit testing framework (junit)
• package: package the compiled files, such as: jar, war, etc.
• install: install the project to the local repository
Maven's lifecycle is abstract, which means that the lifecycle itself doesn't do any real work. In Maven's design, the actual tasks (such as source code compilation) are done by plugins.
In order to make it easier for programmers to use the maven life cycle, the IDEA tool has given a quick access channel in the maven toolbar on the right
The order of the life cycle is: clean --> validate --> compile --> test --> package --> verify --> install --> site --> deploy
What we need to focus on is: clean --> compile --> test --> package --> install
Explanation: In the same life cycle, when we execute the later life cycle, the previous life cycle will be executed.
Thinking: When the package life cycle is running, will the clean and compile life cycles run?
clean will not run, compile will run. Because compile and package belong to the same life cycle, but clean and package do not belong to the same life cycle.
4.4.2 Execution
In daily development, when we want to execute the specified life cycle, there are two execution methods:
In the maven toolbar on the right side of the idea tool, select the corresponding life cycle, double-click to execute
In the DOS command line, execute through the maven command
Method 1: Execute the life cycle in the idea
Method 2: Execute the life cycle on the command line