Maven is an open source project management tool from Apache. Maven uses the concept of the Project Object Model (POM-Project Object Model), a software Project management tool that can manage the construction, reporting, and documentation of a Project with a short description of information. In Maven, every project is an object, and there are relationships between objects (projects). Relationships include: dependency, inheritance, and aggregation. The implementation of Maven projects can more easily achieve the effects of guiding JAR packages, splitting projects, etc.

1. Maven directory structure

  • Bin: stores executable files
  • Conf directory: Below this directory is a very important configuration file — Settings. XML — maven’s core/global configuration file.

2. The maven repository

Maven repository is a service that centrally manages Java API resources (artifacts) based on simple file system storage. Each component in the repository has its unique coordinate, according to which its unique storage path in the repository can be defined. Thanks to Maven’s coordinate mechanism, any Maven project uses any of the artifacts in exactly the same way. Maven can store the shared artifacts of all Maven projects in a unified location. This unified location is called the repository. After the project is built, the generated artifacts can also be installed or deployed to the repository for other projects to use.

For Maven, repositories fall into two categories: local and remote.

2.1 Remote Warehouse

All warehouses not in the machine are remote warehouses: there are central warehouses and local private server warehouses

  • Remote repositories refer to other types of repositories accessed through various protocols such as file:// and http://.
  • Remote repositories may be actual remote repositories set up by third parties to provide downloads of their artifacts (for example, repo.maven.apache.org and uk.maven.org are Maven’s central repositories).
  • Remote repositories may be your company-owned internal repositories built on file or HTTP servers (not Apache’s central repository, but your own Maven repository on the local area network) to share private artifacts and manage releases among development teams.

The default remote repository uses the central repository provided by Apache: MvnRepository.com/

2.1.1 Mirroring warehouse

If repository A can provide all the content stored in repository B, then A can be considered A mirror of B. For example: in the country directly connected to the central warehouse download dependency, due to some special reasons download speed is very slow. At this time, we can use ali cloud with mirror maven.aliyun.com/nexus/conte… To replace the central warehouse repol.maven.org/maven2/. Change maven’s setting. XML file to the following:

<mirror> 
    <! -- specify the image ID -->
    <id>nexus-aliyun</id> 
    <! -- Match the central warehouse (aliyun warehouse name, can not own name, must write so) -->
    <mirrorOf>central</mirrorOf>
    <! -- Specify the image name -->   
    <name>Nexus aliyun</name> 
    <! -- specify mirror path (mirror address) -->            
    <url>http://maven.aliyun.com/nexus/content/groups/public</url> 
</mirror>
Copy the code

2.2 Local Repository

A local repository is a copy of your machine that is used to cache remote downloads and contains temporary artifacts that you have not yet published.

A local repository is a directory on a developer’s local computer that caches artifacts downloaded from a remote repository. The default local repository is ${user.home}/.m2/repository. The local repository can be modified using the settings. XML file. The specific contents are as follows:

<! -- Local repository configuration -->
<localRepository>Specifies the local warehouse location</localRepository>
Copy the code

2.3 Priority of the warehouse

3. The JDK configuration

The default JDK version can be specified through the Maven configuration file

<profile>                
    <! -- settings. XML -->                
    <! -- Tell Maven we are using jdk1.8 -->                
    <id>JDK - 1.8 -</id>                
    <! -- Enable use of JDK -->                
    <activation>                                
        <activeByDefault>true</activeByDefault>                                
        <jdk>1.8</jdk>                
    </activation>                
    <properties>                        
        <! -- Configure compiler information --> 
        <maven.compiler.source>1.8</maven.compiler.source>                     
        <maven.compiler.target>1.8</maven.compiler.target>                    
        <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>  
    </properties>    
</profile>
Copy the code

4. Maven project structure (IDEA as an example)

  • SRC: contains all of the project’s source and resource files, as well as other project-related files.
    • SRC /main/ Java: This is the directory where the Java source code is stored
    • SRC /main/resources: Stores the main resource files. Such as XML configuration files and properties files
    • SRC /test/ Java: Test classes are stored in this directory. For example, JUNIT tests are stored in this directory. Since the test classes themselves are not part of the project, it would be awkward to put them under any one package.
    • SRC /test/resources: You can create your own resource files to store the test environment
  • Target: The folder where the compiled content will be placed
  • Pom. XML: is Maven’s basic configuration file. Configure projects and relationships between projects, including configuration dependencies, and so on

Maven project structure under IDEA is as follows:

--MavenDemo Project name -- idea Project configuration, automatically generated, no need to pay attention to. -- SRC -- main Actual development content -- Java write packages and Java code, this file by default only compile. Java file --resource all configuration files. The final compilation puts the configuration file into the CLASspath. Java stores all the configuration content of the entire Maven project in the test class POM.xml.Copy the code

Note: Directory names cannot be changed because maven uses this directory structure for compilation or jar generation.

5. Maven project type

  • POM engineering: POM engineering is logic engineering. Used in parent or aggregate projects. It is used for versioning jar packages.
  • JAR project: will be packaged as jars and used as JAR packages. That is, the common local Project -> Java Project.
  • WAR Project: A project that will be packaged as a WAR and published on a Web server.

5.1 Engineering Relationships in POM mode

5.1.1 Dependency transitivity

Transitive dependencies are a new feature in Maven2.0. Suppose your project depends on one library, which in turn depends on other libraries. You don’t have to find all of these dependencies yourself, you just need to add the libraries that you directly depend on, and Maven will implicitly add the libraries that these libraries indirectly depend on to your project. This feature is implemented by resolving library-dependent project files retrieved from a remote repository. Typically, all dependencies of these projects are added to the project, either inherited from the parent project or through transitive dependencies.

If A depends on B, then C depends on A and automatically imports both A and B.

Project dependencies follow two principles

  • First principle: Shortest path first principle

Shortest path first means that the version with the shortest path in the project dependency tree is used.

For example, suppose the dependencies between A, B, and C are A->B->C->D(2.0) and A->E->(D1.0), then D(1.0) will be used because the path from A to D through E is shorter.

  • The second principle: declare the principle first

The first rule does not solve all problems when dependency paths are of the same length, such as dependencies like this:

  • A – > B – > Y (1.0),
  • A – > – > Y C (2.0),

The dependent path length of Y(1.0) and Y(2.0) is the same, which is 2. So who will be parsed? In Maven 2.0.8 and earlier, this was uncertain, but since Maven 2.0.9, in order to avoid build uncertainty as much as possible, Maven has defined the second principle of dependency mediation: first claim first. The order in which dependencies are declared in the POM determines who will be parsed, provided the length of the dependency paths is equal. The one at the top of the order depends on winning.

5.1.2 Removing dependencies

Exclusions. exclusions. can be configured with multiple Exclusion tags, and each Exclusion tag corresponds to groupId, artifactId, and version. Note: Do not write the version number.

For example, A– >B– >C (Mybatis. Jar) excludes Mybatis. Jar from C

5.1.3 Dependency Range

The range of dependencies determines when the coordinates you depend on are valid and when they are not:

  • Compile: This is the default range. If not specified, the dependency scope is used. Indicates that the dependency is in effect at compile and run time.

  • Provided: Provided dependency scope. Use Maven dependencies for this dependency scope. A typical example is servlet-API, which is required to compile and test the project, but is not required to be introduced repeatedly by Maven when running the project because the container already provides it (e.g., servlet-API).
  • Runtime: the runtime range indicates that it does not need to take effect at compile time, but only at runtime. A typical example is a JDBC driver implementation. The main code of a project requires only the JDBC interface provided by the JDK for compilation, and only the specific JDBC driver that implements the above interface is required when executing tests or running the project.
  • System: System scope is similar to provided, but you must explicitly specify a JAR in the local system path. This dependency should always be in effect and Maven will not look for it in the repository. However, when using system range dependencies, you must explicitly specify the path to the dependent file through the systemPath element.
  • Test: The test scope indicates that the dependencies that use this scope are required only when compiling test code and running tests, and are not required for the proper operation of the application. A typical example is JUnit, which is required only when compiling test code and running tests. When you export the project, you don’t have to go anywhere with Junit. Just add scope test to the Junit coordinates
  • Import: The import scope applies only to parts of the POM file. Indicates that the specified POM must use partial dependencies, and the version number is mandatory. Subprojects must use the version number of the dependency package, otherwise an error will be reported. Note: Import can only be used within the scope of dependencyManagement.

5.1.4 Engineering relationship-inheritance

If project A inherits project B, project A depends on all the resources that project B depends on by default, and can apply all the resource information defined in project B. The inherited project (project B) can only be a POM project.

Note: The contents placed in the parent project are not inherited from the project and cannot be directly used for versioning purposes. The coordinates only need to be filled in and when the contents are dependent in the subproject. (Note: If the child project does not want to use the version of the parent project, you can explicitly configure the version).

The parent project is a POM project:

Create a sub-project:

5.1.4 Engineering relationship – aggregation

When we develop projects with more than two modules, each module is a separate set of functions. For example, a university system has search platform, learning platform, examination platform and so on. Each platform can be independently compiled, tested, and run during development. This is where we need a polymerization project.

In the process of creating an aggregation Project, the overall Project must be a POM Project. (The aggregation Project must be a POM Project, but the JAR Project or war Project cannot be an aggregation Project). The submodules can be any type of modules.

Premise: Inheritance.

Aggregation contains inherited features.

When aggregated, multiple projects are still essentially one project. These projects are contained by a large parent project. The parent project type is POM. It also appears in the parent project’s POM.xml to represent all the included submodules.

General Project: General Project: POM project

6. Common plug-ins

6.1 Compiler plug-ins

With the compiler plug-in, we can configure the JDK or compiler version to be used:

To configure the global compiler plug-in in settings. XML, find the Profiles node and add the profile node to it:

<profile>
    <! -- plugin ID defined by the plugin -->
    <id>JDK - 1.7 -</id>
    <! -- Plugin tag, activeByDefault: true default compiler, JDK provides compiler version -->
    <activation>
        <activeByDefault>true</activeByDefault>
        <jdk>1.7</jdk>
    </activation>
    <! -- configuration source-source, target-bytecode, compilerVersion -->
    <properties>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>               
        <maven.compiler.compilerVersion>1.7</maven.compiler.compilerVersion>
    </properties>
</profile>
Copy the code

Configuration compiler plug-in: POM.xml configuration fragment

<! -- Configure the Maven compile plugin -->
<build>
    <plugins>
    <! --JDK compiler plug-in -->
        <plugin>
            <! -- Plug-in coordinates -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.2</version>
            <! -- -->
            <configuration>
                <! -- source code using JDK version -->
                <source>1.7</source>
                <! -- The version of the source code compiled to the class file, as above -->
                <target>1.7</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

6.2 Plug-in for Resource Copy

By default, Maven only copies configuration files from SRC /main/resources to the project and packages them. Configuration files from non-resource directories are not added to the project.

SRC /main/resources and then we pack the configuration file in the target classes section below:

If you want to package files other than resources into classes: you need to configure: pom.xml configuration fragment (copy all XML files in SRC /main/ Java and its subfolders at compile time) :

<build>
    <resources>
        <resource><-- copy all XML files in SRC /main/ Java and its subfolders at compile time --><directory>src/main/java</directory>
            <includes>
                <include>**/*.xml</include>
            </includes>
        </resource>
        <resource>
            <directory>src/main/resources</directory>
            <includes>
                <include>**/*.xml</include>
                <include>**/*.properties</include>
            </includes>
        </resource>
    </resources>
</build>
Copy the code

6.3 the tomcat plug-in

If we create a WAR project, we must deploy it on a server by (1) deploying it on a remote server

(2) Associate IDEA with external Tomcat, and then deploy the project on external Tomcat

Instead of relying on external Tomcat, Maven provides a Tomcat plug-in that you can configure to use.

To publish and execute a war project using the Tomcat plug-in, run the tomcat7:run command. Tomcat7 in the command is the plug-in name, as determined by the plug-in provider. Run is the specific function in the plug-in.

(Note: the compiler plugin and resource copy plugin are not working plugins. Maven runs them directly for us, but Tomcat is a working plug-in. The programmer needs to control when and how it works. We must run control by command)

The configuration of the pom. XML file is as follows:

<build>
    <plugins>
    <! -- Configure the Tomcat plug-in -->
        <plugin>
            <groupId>org.apache.tomcat.maven</groupId>
            <artifactId>tomcat7-maven-plugin</artifactId>
            <version>2.2</version>
            <configuration>
                <! -- configure the Tomcat listening port -->
                <port>8080</port>
                <! -- Configure the project access path (Application Context) -->
                <path>/</path>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

7. Maven command

  • Install: Local installation, including compilation, packaging, and installation to a local repository
    • Compile – javac
    • Package -JAR to package Java code as a JAR file
    • Install to local repository – Save the packaged JAR file to the local repository directory.
  • Clean: Deletes compiled information. Delete the target directory from the project.
  • Compile: Only compile. Javac command
  • -Chuck: Package it. Includes compilation and packaging.

7.1 Differences between Install and Package:

  • The package command compiled, unit-tested, and packaged the project, but it did not deploy the typed executable jars (war packages or other forms of packages) to the local Maven repository or remote Maven private server repository
  • The install command compiles, unit-tests, packages, and deploys the packaged executable jars (war packages or other packages) to the local Maven repository, but not to the remote Maven private repository