Foreword: At present, all the projects are using Maven, but I have no time to tidy up and learn. I just have time to tidy up well these two days.

Build tools like Maven

① A project is a project

If the project is very large, it is not suitable to use package to divide modules. It is better that each module corresponds to a project, which is conducive to division of labor and cooperation. Maven allows you to split a project into multiple projects

② The jar package is used in the project, you need to “copy” and “paste” the project lib

The same JAR package appears repeatedly in different projects, you need to do a lot of copy and paste work. With Maven, jars can be stored in a “repository” regardless of which project you are working on using a reference.

③ When you need jar packages, you should prepare them by yourself or download them from the official website

With Maven we can download jar packages, specifications, in a uniform specification way

④ Risk of inconsistent JAR package versions

When jar packages are used by different projects, the versions of jar packages of different projects may be inconsistent, resulting in unexecuted errors. With Maven, all jars are placed in the repository, and all projects use a copy of the jar from the repository.

⑤ A JAR package depends on other JAR packages and needs to be manually added to the project

FileUpload component ->IO component, commons-fileupload-1.3.jar depends on commons-io-2.0.1.jar

It greatly wastes the time cost of importing the package and also greatly increases the learning cost. With Maven, it automatically imports dependent JAR packages.

What is Maven?

Maven is an automated build tool for the Java platform

make->Ant->Maven->Gradle

Name: we can call mei Wen or Maiwen, but no one called Ma Wen.

(2) build

Build definition: The process of deploying the compiled results of a dynamic Web project to a server.

Compile: Java source file [.java]-> compile ->Classz bytecode file [.class]

Deployment: Instead of a dynamic Web project, you end up deploying a compiled file in the Sevlet container

③ Each link of construction

  • Clean clean: Removes the old class bytecode files from the previous compilation

  • Compile: Compile Java source programs into class bytecode files

  • Test: Automatic test, automatic call junit program

  • Report report: Results of test program execution

  • Package package: War package for dynamic Web projects, JAR package for Java projects

  • Install install: Maven-specific concepts —– copy the packaged files to the specified location in the repository

  • Deploy: Copy the WAR package generated by the dynamic Web project into the Servlet container and make it ready to run

Install Maven

① Check whether the JAVA_HOME environment variable is configured in the current system

② Download maven and unzip maven to a non-Chinese without Spaces directory

3. Configure maven environment variables

  • Add M2_HOME to the environment variable. The path is maven’s decompressed root directory

  • Add the maven/bin directory to the path of the environment variable

④ Verification: maven -v Displays the Maven version

See the version information, congratulations you are OK.

The first Maven

Maven projects must be created according to the convention directory structure.

Root directory: project name | – SRC: source | — – | — – the main: store the main program | — – | — – | – Java: Java source code file | — – | — – | — – the resource: deposit framework configuration file | — – | — – the test: Storage test program | – pop. XML: maven core configuration file

Let’s create it manually using the folder directory structure above, without using any IDE (manual is actually the best way to understand Maven).

The file contents are as follows

In SRC/main/Java/com/HZG/maven directory file new Hello. Java, content is as follows

package com.hzg.maven; Public class Hello {public String sayHello(String name){return "Hello "+name+"!" ; }}Copy the code

POM file contents:

<? The XML version = "1.0"? > < project XMLNS = "http://maven.apache.org/POM/4.0.0" XMLNS: xsi = "http://www.w3.org/2001/XMLSchema-instance" Xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > < modelVersion > 4.0.0 < / modelVersion > < groupId > com. HZG. Maven < / groupId > < artifactId > Hello < / artifactId > <version>0.0.1-SNAPSHOT</version> <name>Hello</name> <dependencies> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.0</version> <scope>test</scope> </dependency> </dependencies> </dependencies> </project>Copy the code

② Common maven commands

  • MVN clean: indicates cleaning

  • MVN compile: Compiles the main program

  • MVN test-compile: compiles test programs

  • MVN test: Executes a test

  • MVN package: package

  • MVN install: indicates the installation

To run the maven command, go to the pom. XML directory

After entering the project’s POM.xml directory, you are ready to execute.

1. Run MVN compile

The dependency packages you configured in pom.xml have been imported into the repository. Where is the repository’s default location?

** Default repository location: ** C :Usrs[current system user name].m2repository

After compiling, the previous folder has changed

We noticed an extra target folder in the Hello project. The contents of the folder are:

It is found that the target mainly stores the compiled bytecode file

< span style = “box-sizing: border-box; color: RGB (51, 51, 51); line-height: 22px; font-size: 14px! Important; white-space: normal; word-break: normal

3, run the MVN package, target folder below another hit jar package

4, Run MVN clean and find that the entire target folder is gone. Back to the folder we created manually before compiling

Warehouse and coordinates

**① POM.xml: **Project Object Model It is the core configuration file for Maven, where all build configurations are set.

** coordinates: ** Uniquely locate a Maven project in the repository using the following three vectors

③ The relationship between maven project coordinates and paths in the warehouse:

Maven coordinates are mapped to repositories: [groupId][artifactId][version][artifactId]-[version].jar

Go to your local repository and look at this directory: orgSpringFrameworkSpring-core4.3.4.releasespring-core-4.3.4.release.jar

Sure enough, it is exactly the same (the default warehouse address has been mentioned above, don’t say I don’t know where, it’s ok, let’s talk about the warehouse again)

(4) the warehouse

Classification of warehouse:

**1, local repository: ** the repository on the current computer, the path has already said oh

2. Remote warehouse:

  • Private server: set up in the LAN, the general company will have private server, private server generally use nexus to set up. You can inquire other information about the specific construction process

  • Central repository: on the Internet, like the springframework is on a central repository

Six, rely on

Maven retrieves dependent jar packages from the local repository when parsing dependency information

  • For those not in the local repository, the maven coordinates will be searched in the central repository to obtain the JAR package. After obtaining the JAR, it will be downloaded to the local repository

  • When the central repository cannot find the dependent JAR package, the compilation will fail

② If you rely on maven projects developed by yourself or your team, run the install command to import the jar packages of the dependent Maven projects to the local repository

Example: Now I create a second Maven project HelloFriend that uses the sayHello(String name) method from the first Hello project. When compiling the HelloFriend project with the MVN compile command, we will be prompted that the jar package that depends on Hello is missing. What to do?

After you execute MVN install in your first Maven project, check the local repository and you’ll find the Hello project jar. Once you have the jar packages of the maven project to rely on, you can compile them successfully when you use the MVN compile command in the HelloFriend project

③ Scope of dependence

Scope is the scope of a dependency

**1, compile, ** default value, for all phases (development, test, deployment, run), this JAR will always exist at all phases.

Provided, ** is only used during development and testing so that the Servlet container does not conflict with the JAR packages in your local repository. Such as servlet. The jar.

Runtime, ** only used at runtime, such as JDBC drivers, for run and test phases.

**4, test, ** only used during testing, used to compile and run the test code. Does not ship with the project.

Maven does not look for the jar containing the dependency in the Repository.

Life cycle

Maven has three separate life cycles. Note that it says “three” and “independent.” It is easy for beginners to see Maven’s life cycle as a whole, but it is not. The three life cycles are:

**① Clean Lifecycle does some cleaning prior to the actual build. ** The Clean lifecycle consists of three phases:

  • Pre-clean performs some work that needs to be done before Clean

  • Clean removes all files generated during the last build

  • Post-clean Performs some work that needs to be done immediately after clean

② The core parts of a Default Lifecycle build, compile, test, package, deploy, etc.

  • validate

  • generate-sources

  • process-sources

  • generate-resources

  • Process-resources copies and processes the resource files to the destination directory, ready for packaging

  • Compile the source code of the project

  • process-classes

  • generate-test-sources

  • process-test-sources

  • generate-test-resources

  • Process-test-resources copies and processes the resource files to the target test directory

  • Test-compile compiles the test source code

  • process-test-classes

  • Test runs tests using an appropriate unit testing framework. The test code will not be packaged or deployed

  • prepare-package

  • A package takes compiled code and packages it into a publishable format, such as a JAR

  • pre-integration-test

  • integration-test

  • post-integration-test

  • verify

  • Install installs packages into a local repository for other projects to rely on.

  • Deploy copies the final package to a remote repository for other developers to share with the project

So let’s run the MVN install command in Hello’s project and see what happens in the log.

From the log, we find that MVN install is actually executed with compile and test already executed.

** Summary: ** No matter which phase of the life cycle you execute, Maven executes at the beginning of the life cycle

** Plugins: ** Each stage has plugins, see the ones highlighted in red above. The plug-in’s job is to execute its corresponding command.

③ Site Lifecycle will produce a report on the project.

  • Pre-site performs some work that needs to be done before generating site documentation

  • Site generates site documentation for the project

  • Post-sites perform some of the work that needs to be done after the site documentation is generated and ready for deployment

  • Site-deploy deploates the generated site documents to a specific server

Use Maven in Eclipse

(1), configuration,

Select Windows –> Preferences –> Maven

Select your Own Maven directory, which you download and decompress. Check √ and hit Apply.

Select the User Settings directory, select Browse from the User Settings directory, and select settings.xml from your Own Maven conf file.

Settings. XML is a configuration file that configures the path to your local repository. If you don’t want to use the default path, open the file and add your own path configuration.

<localRepository>C:Program FilesJavarepository</localRepository>
Copy the code

At this point, maven’s entire setup is OK.

② Use Eclipse to create A Web project for Maven

1. Choose File > New > Project and enter Maven

Select Maven Project and click Next

Click Next

Enter WebApp, select the first item, and click Next

The project is created, but the JDK version and sevlet-API jar packages are not yet available

Right-click the created project, select Properties and go to Java Build Path to select the correct JDK version on your computer.

Right-click the created Project, select Properties Facets and find Project Facets, select 3.1 for version, select 1.8 for Java version below, and click Apply

Right-click the created project and find build Path

Go to Libaries, add the Tomcat8.5 dependent library, and click OK

Maven project dependencies advanced features

① Transitivity of dependence

The WebMavenDemo project depends on JavaMavenService1

After configuring dependencies in the POM. XML file, you must install MVN before using the dependent JAR package.

  • JavaMavenService1 must install MVN to compile the pom. XML file for WebMavenDemo

  • To compile JavaMavenService’s pom. XML file, JavaMavenService2 must be installed by MVN

Transitivity:

In Eclipse, when you add a spring-core-jar package to JavaMavenService2, you’ll be surprised to find that both dependent projects automatically add the JAR package, which is transitivity of the dependency.

Note: Dependencies that are not in the compile scope cannot be passed.

② Principle of version dependence:

1. Shortest path first

The WebMavenDemo project follows the shortest path first rule, and the version of log4j is the same as that of Sercive1.

2. If the paths are the same, declare priority first

This scenario dependency has changed. The WebMavenDemo project relies on Sercive1 and Service2, both of which are the same path, so whoever declared the dependency first in WebMavenDemo’s pom.xml will use the version.

③ Unified management of dependent versions:

To manage the version number uniformly, you can use the Properties TAB, where you can customize the version label name. Use ${custom tag name} where used

X. Build configuration

The < build > <! -- Project name --> <finalName>WebMavenDemo</finalName> <! -- Describe the location of resources in the project --> <resources> <! -- Customize resource 1 --> <resource> <! SRC /main/ Java </directory> <! - including what files involved in packaging - > < includes > < include > / *. * * XML < / include > < / includes > <! -- out of which files are not involved in packaging - > < excludes > < exclude > / * * *. TXT < / exclude > < exclude > / * * *. Doc < / exclude > < / excludes > < / resource > < resources > <! Plugins </groupId> org.apache.maven.plugins</groupId> < artifactId > maven -- the compiler plugin < / artifactId > < version > 2.1 < / version > < configuration > <! <source>1.8</source> <! <target>1.8</target> </configuration> </plugin> <! Plugins --> < plugins > <groupId>org.apache.maven.plugins</groupId> The < artifactId > maven - resources - the plugin < / artifactId > < version > 2.1 < / version > < executions > <execution> <phase>compile</phase> </execution> </executions> <configuration> < encoding > utf-8 < / encoding > < configuration > < / plugin > <! Plugins </groupId> org.apache.maven.plugins</groupId> The < artifactId > maven - war - the plugin < / artifactId > < version > 2.1 < / version > < configuration > <! <warName>WebMavenDemo1</warName> </configuration> </plugin> </plugins> </build>Copy the code

After the build is configured and the MVN package is executed, the WAR package and file are generated as configured in the target directory specified by the Maven project

Well, that’s all for Maven.