Maven is a pure Java development open source project under Apache. Based on the Project Object Model (POM) concept, Maven uses a central piece of information to manage the construction, reporting, and documentation steps of a project. It is a project management tool for building and dependency management of Java projects.

convention

Maven uses the principle of convention over configuration, advocating a common standard directory structure.

Until I learned this, I thought ${basedir}/ SRC /main/ Java was an existing convention of Java projects, and not maven’s convention was greater than configuration.

directory role
${basedir} Store POM.xml and all subdirectories
${basedir}/src/main/java Java source code for the project
${basedir}/src/main/resources Project resources such as property files, SpringMVC. XML, application.yml
${basedir}/src/test/java Test classes for the project, such as Junit code
${basedir}/src/test/resources Resources for testing
${basedir}/src/main/webapp/WEB-INF Directory of Web application files, information about Web projects, such as web.xml, local images, JSP view pages
${basedir}/target Package output directory
${basedir}/target/classes Compile output directory
${basedir}/target/test-classes Test the compile output directory
Test.java Maven automatically runs only test classes that conform to this naming convention
~/.m2/repository The default location of Maven’s local repository directory

The plug-in

Maven has three standard life cycles:

  • Clean: Handling project cleaning
  • Default (or Build) : Handling of project deployment
  • Site: Processing of project site document creation

Each life cycle contains a series of phases. These phases act as a unified interface provided by Maven, and the implementation of these phases is done by Maven plug-ins.

When we input MVN command, for example, MVN clean, clean corresponds to the clean phase of the clean lifecycle. The specific operation of clean is implemented by maven-clean-plugin.

Maven is actually a framework that relies on plug-ins to perform tasks that are actually done by plug-ins. By default, Maven binds default plug-ins to perform basic operations.

plugin function life cycle phase
maven-clean-plugin Cleans up the target file created last time clean
maven-resources-plugin Process source and test resource files resources,testResources
maven-compiler-plugin Compile and test the source files compile,testCompile
maven-surefire-plugin Execute test file test
maven-jar-plugin Create the jar jar
maven-install-plugin Install the jar and copy the generated jar to.m2/repository install
maven-deploy-plugin Release the jar deploy

If there are special configurations for individual plugins, the specified plugin and property configurations need to be displayed. For example, bulid

     <build>
         <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
         </plugins>
    </build>
Copy the code

warehouse

A Maven repository is a third-party library that a project relies on. The repository is located in a location called a repository.

Maven repositories come in three types:

  • Local
  • Central
  • Remote (remote)

The local repository, which is not created after installing Maven, is created when the Maven command is first executed. Maven local repositories are created in the %USER_HOME% directory by default. To change the default location, define another path in Maven’s settings.xml file in the %M2_HOME%\conf directory.

The central repository, provided by the Maven community, contains a large number of commonly used libraries. The central repository contains most of the popular open source Java artifacts, as well as source code, author information, SCM, information, license information, and so on.

Remote repository, which is a developer’s custom repository that contains the required code base or other JAR files used in the project.

Maven relies on search order

When we execute the Maven build command, Maven starts looking for dependent libraries in the following order:

  • Step 1 – Search the local repository. If it cannot be found, perform Step 2. If it is found, perform other operations.
  • Step 2 – Search the central repository. If it cannot be found and one or more remote repositories have been set up, perform Step 4. If found, download to the local repository for future reference.
  • Step 3 – If the remote repository is not set up, Maven simply stalls processing and throws an error (the dependent file cannot be found).
  • Step 4 – Search one or more remote repositories for the dependent files, and if found, download them to the local repository for future reference, otherwise Maven will stop processing and throw an error (the dependent files cannot be found).

About configuring the remote repository

Configure the Remote repository for the Maven project using the repository tag in POM.xml. Such as:

<repositories>  
        <repository>  
            <id>alimaven</id>  
            <name>aliyun maven</name>  
            <url>http://maven.aliyun.com/nexus/content/groups/public/</url>  
            <releases>  
            <! You can download the releases version from this repository.
                <enabled>true</enabled>  
            </releases>  
            <snapshots>  
            <! -- Do not download the Snapshot version from this repository -->
                <enabled>false</enabled>  
            </snapshots>  
        </repository>  
</repositories>
Copy the code

About version Number

A comment from Cainiao about the Maven version:

1. Snapshot version represents an unstable version that is still under development.

2. A Release represents a stable version.

3. When should SNAPSHOT be used?

In collaborative development, if A depends on component B, B should identify itself with SNAPSHOT because B will update. The need for this practice can be disproved as follows:

A. If B does not use SNAPSHOT but uses a stable version after each update, the version number will increase too fast, one liter per day or even one liter per hour, which would be an abuse of the version number. B. If B does not use SNAPSHOT but keeps using A single Release number, A may not receive the update when B updates. Because the repository used by A does not update the release version cache frequently (i.e. the local repository), A does not download the latest version of B from A remote Repository after B updates it with the same version number

4. How about using SNAPSHOT everywhere instead of Release?

I can’t. The snapshot version of the library cannot be used in a formal environment. For example, if you successfully build your application today with a snapshot version of a third-party library, you may fail tomorrow because tonight a third party may have updated its Snapshot library. When you build again, Maven will go to remote Repository and download the latest version of Snapshot. The library you built with is the new JAR file, and correctness is not guaranteed.

Reference:

www.runoob.com/maven/maven…

www.manongjc.com/detail/7-se…

www.jianshu.com/p/977b71e28…