Maven: background, build, build link, installation, common commands, directory structure, POM, coordinates, dependencies, warehouse

Introduction

Background [why]

Why should we learn this Maven? According to the technology we have learned so far, it is already possible to do a project. Now we have the knowledge:

using the previous technology, we can already do a complete project, but there are many The problem, the
current technology in the development of problems

1. A project is a project
   If the project is very large, it is not suitable to continue to use packages to divide modules. It is best that each module corresponds to a project to facilitate division of labor and collaboration.
   With the help of Maven, a project can be split into multiple projects.

2. The jar package needed in the project must be manually "copy" and "pasted" into the WEB-INF/ib directory.
   The problem is that the same jar package file appears repeatedly in different projects, which wastes storage space on the one hand and on the other It also makes the project bloated.
   With the help of Maven, the jar package can only be stored in the "repository", and the file interface of the project that needs to be used is "referenced" without actually copying the jar package.

3. The jar package needs to be prepared for us by others, or downloaded
   from the official website. There are many ways to download the jar package from the official website of different technologies.
   The official websites of some technologies are available for download through special tools such as Maven or SVN.
   If the jar package is downloaded in an irregular way, then the content is probably also irregular.
   With the help of Maven, jar packages can be downloaded in a standardized way. Because all well-known frameworks or third-party tool jar packages and in accordance with a unified specification are stored in the central warehouse of Maven.
   The content of the jar package downloaded in a standardized way is also reliable.

4. Other jar packages that a jar package depends on need to be manually added to the project by the
   FileUpload component-I0 component. commons-fileupload-1.3.jar depends on commons-io-2.0.1.jar.
   If the dependencies between all jar packages need to be clearly understood by the programmer himself, then it will greatly increase the cost of learning.
   Maven will automatically import the dependent jar packages.

What is Maven[What]

Maven is an automated build tool for the Java platform.
Process experienced: Make→Ant→Maven→Gradle After you
understand Maven, you can learn about Gradle

Construct

Concept: Use "Java source files", "frame configuration files", "JSP", "HTML", "pictures" and other resources as "raw materials" to "produce" a runnable project.
Building is not creating, and creating a project does not mean building a project. To understand the meaning of construction, we should look at the following three levels from the shallower to the deeper:
①Pure Java code, as everyone knows, our Java is a compiled language, and source files with a .java extension need to be compiled into a .class extension The bytecode file can be executed. So if you write any Java code that you want to execute, it must be compiled to get the corresponding .class file.
②Web project When we need to access the Java program through the browser, we must "get" the compiled result of the Web project containing the Java program to the designated directory on the server and start the server. This "taking" process is called deployment.
③The actual project integrates a third-party framework in the actual project. In addition to static resources such as Java programs and JSP pages and pictures, the Web project also includes the jar packages of the third-party framework and various configuration files. All these resources must be deployed on the server according to the correct directory structure before the project can run.

Three aspects correspond to these three processes: compilation -> deployment -> build
compilation : Java source file [Userjava]-compile a Class bytecode file [User.clas]-hand over to VM to execute
deployment : a BS project finally runs It is not the dynamic Web project itself, but the "compilation result" of this dynamic Web project. It
can be found that after compilation, the WebContent directory does not exist. The name of the project is the largest directory. The content under WebContent is compiled and placed in the project directory. , The result of src compilation is placed in the WEB-INF class path. During the
development process, all paths or class paths configured in the configuration file are based on the directory structure of the compilation result.

Understanding
of operating environment These are operating environments, and the code is not directly in the project file

Part of the build process

Cleanup : delete the old class bytecode file obtained from the previous compilation to prepare for the next compilation.
Compile : program the Java source program into a class bytecode file Test: automatic test, automatically call the junit program
report : test program execution Result
packaging : dynamic Web project to war package, Java project to jar package
Installation : Maven specific concept-copy the packaged files to the specified location in the "warehouse"
Deployment : copy the war package generated by the dynamic Web project to the Servlet The specified directory of the container, so that it can run

Install Maven

1. Because Maven is originally written in java, it also needs the operating environment of jvm to check whether the computer has the JAVA_HOME environment variable
2. Unzip your Maven archive
3. Configure
   the variable name of Maven's related environment variable MAVEN_HOME, which corresponds to the
   path path of the upper level directory of the bin of the decompressed Maven compressed package, and the next level directory of the bin of the decompressed Maven package
4. Allow mvn -v to view the version of maven, if you can see it, it means success

The core concept of Maven

Commonly used Maven commands

Note: To execute Maven commands related to the build process, you must enter the directory where pom.xml is located.
Related to the build process: compile, test, package,...

Common commands
[1] mvn clean: clean up
[2] mvn compile: compile the main program
[B] mvn test-compile: compile the test program
[4] mvn test: execute the test
[5] mvn package: package
[6] mvn install: Install
[7] mvn site: generate site information, which is html information

The first time you execute the above command, you need to connect to the Internet, because Maven needs some plug-ins, and your computer does not, he will go to the central warehouse to download it back to you

① Only the abstract life cycle is defined in the Maven core program, but the specific work must be completed by a specific plug-in. The plug-in itself is not included in the core Maven program.
②When the Maven commands we execute need to use some plug-ins, the Maven core program will first look in the local warehouse.
③The default location of the local warehouse: [home directory of the current user in the
system.m2 \repository ④If the Maven core program cannot find the required plug-in in the local warehouse, it will automatically connect to the external network and download it to the central warehouse.
⑤If the external network cannot be connected at this time, the construction will fail.
⑥ Modifying the location of the default local warehouse allows the Maven core program to find the plug-in in the directory we prepared in advance
[1] Find the Maven decompression directory \confAsettings.xml
[2] Find the localRepository tag in the settings.xml file
[3] Change < localRepository>/path/to/local/repo< /localRepository> Take out from the comments
[4] Modify the content of the tag body to the prepared Maven warehouse directory

Conventional directory structure

Create an agreed directory structure
[1] Root directory: project name
[2] src directory: source code
[B] pom.xm file: Maven project core configuration file
[4] main directory: store the main program
[5] test directory: store Test program
[6] ljava directory: store Java source files
[7] resources directory: store the configuration files of frameworks or other tools,

why should we comply with the agreed directory structure?
Maven is responsible for the automated construction of our project. Take compilation as an example. For Maven to automatically compile, it must know where the Java source files are stored.

If we want to let the framework or tools know about our own custom things, there are two ways:
explicitly tell the framework by configuration to
comply with the existing conventions in the framework

The future trend is convention>configuration>coding

POM

①Meaning : Project Object Model is
similar to DOM Document Object Model.
②pom.xm is the core configuration file for Maven project, and all settings related to the build process are configured in this file.
The degree of importance is equivalent to that of web.xml for dynamic Web projects

coordinate

It can be analogous to coordinates in
mathematics. Coordinates in mathematics:
using two vectors of X and Y on the plane can uniquely locate any point in the plane, and three vectors of X, Y, and Z can be used in the space to uniquely locate the space
The coordinates of any point in Maven:
use three vectors to uniquely locate a Maven project
groupid in the warehouse : company or organization domain name + project name
artifactid module name
version version
The coordinates of the Maven project correspond to the path in the warehouse, for example :

<groupld>org.springframework</groupld>
<artifactld>spring-core </artifactld>
<version>4.0.0.RELEASE</version>
对应文件路径:
org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar
路径是groupld+artifactld+version
文件名称:模块名-版本号.jar

rely

That is, the classes of this project need to use the classes of other projects to realize the function. When
Maven resolves the dependency information, it will look for the dependent jar package in the local warehouse.
For the Maven project we developed by ourselves, it can be put into the warehouse after installation using the mvn install command in the project directory.

Scope of dependence

Dependencies are compile, test and provided

1. Compile scope depends
   on whether it is effective for the main program: effective Whether it is effective
   for the test program: effective
   Whether to participate in packaging: participate
2. The scope of test depends
   on whether it is valid for the main program: invalid
   . Whether it is valid for the test program: valid.
   Whether to participate in packaging: not to participate.
   Typical example: junit
3. Provided scope dependency
   Whether it is valid for the main program: valid Whether it is valid
   for the test program: valid
   Whether to participate in packaging: not participating
   Whether to participate in deployment: not participating
   Typical example: servlet-api.jar, for example, when web project development requires servlet and other jar Package, so you need to rely on the servlet-api jar package, but when deploying and running, the servlet api is provided by the servlet container of the tomcat server, and there is no need to rely on other things
   
   
   

Transitivity of dependency

A depends on B and B depends on C. Can A use C? It depends on whether the scope of B depends on C is compile, if it is, it can be used, otherwise it is not.

Exclusion of dependence

If we introduce a dependency of A in the current project, and A depends on B, then Maven will automatically introduce A dependent B into the current project, but in some cases, B may be an unstable version, or the current project Have adverse effects. At this time, we can exclude B when introducing A.
For example:

writing this exclusion information in Hello or HelloFriend, writing in Hello will not affect HelloFriend.

	<dependency>
		<groupId>maven</groupId>
		<artifactId>HelloFriend</artifactId>
		<version>0.0.1-SNAPSHOT</version>
		<type>jar</type>
		<scope>compile</scope>
		<exclusions >
			<exclusion >
				<groupId>commons-logging</groupId>
				<artifactId>commons-logging</artifactId>
			</exclusion>
		</exclusions>
	</dependency>

Principle of dependence

[1] Function: Solve the problem of jar package conflicts between module projects.
[2] Scenario 1: The shortest verification path takes precedence

[3] Scenario 2: When the verification paths are the same, the first statement is the first
to declare first. Declaration order of dependency tags

Unified management of dependent versions

For example, a series of spring frameworks need to be referenced. The version numbers of the spring frameworks generally need to be consistent. If you suddenly need to upgrade all the spring version numbers, what should we do? With
so much dependency information, we cannot be one by one. Go to change
So the recommended configuration method:

1. Use custom tags in the properties tag to uniformly declare data, which is the version number
2. Where a unified version is needed, use $(custom label name) to reference the declared version number.
   For example:
   declare the version number:

	<properties>
		<jane>4.1.1.RELEASE</jane>
	</properties> 

Quote:

		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${
    
    jane}</version>
		</dependency> 

The configuration of the properties tag with custom tags to declare data is not only used to declare the version number of the dependency, it can be used to declare if unified data is required

warehouse

Classification of warehouses

1. Local warehouse:
   the warehouse directory deployed on the current computer, serving all Maven projects on the current computer
2. Remote warehouse
   (1) Private server: built in a local area network environment, serving all Maven projects in the local area network
   (2) Central warehouse: set up on the Internet, serving all Maven projects in the world
   (3) Central warehouse mirroring: in order to share the central Warehouse traffic, improve user access speed

Contents saved in the warehouse : Maven project
[1] Plug-ins needed by Maven itself
[2] Jar packages of third-party frameworks or tools
[B] Maven project developed by ourselves