Introduction to the

  1. Apache Open Source project;

  2. Pure Java development

role

  1. Dependency management

  2. The project build

Classification of the warehouse

  • Local repository
  • Private servers
  • The central warehouse

The directory structure

The life cycle

Maven’s life cycle is to abstract and unify all build processes. Maven’s life cycle is abstract, meaning that the life cycle itself doesn’t do any real work; it just defines a series of phases and determines the order in which those phases are executed. During these phases, the plug-in does the actual work.

Clean Life cycle

1) Pre-clean Perform some work that needs to be done before cleaning. 2) Clean Cleans up the files generated during the last build. 3) Post-clean Perform some work that needs to be done after the cleanup.

Default Life Cycle

All the steps that need to be performed for the “build” of Maven’s core functionality

  1. Process-resources processes the project master resource files. The contents of the SRC /main/ Resources directory are copied to the main classpath directory of the project output after variable substitution and so on.

7) Compile the main source code of the project

  1. Process-test-sources processes the project test resource files

13) test-compile the test code of the project

  1. Test uses the unit testing framework to run tests, and the test code is not packaged or deployed

17) Package takes compiled code and packages it into a releasable format

  1. Install installs packages into Maven’s local repository for use by other Maven projects locally

23) Deploy copies the final package to a remote repository for use by other developers and Maven projects

Site Life Cycle

Build and publish the project site

The command

Command execution logic: The lifecycle of the phase is first obtained and executed sequentially from the first phase to the phase itself. Commands with different declaration periods can be executed simultaneously. For example, MVN Clean Package

Depend on the range

Compile

The default scope

Provided

Jar servlet-api.jar (tomcat container has these two JAR packages, if packaged into the war package, will conflict with Tomcat.

Runtime

Eg: JDBC driver package

Test

eg: junit

Compile Provided Runtime Test
compile Y Y
test Y Y Y Y
packaging Y Y

Depend on the transfer

Introducing one Jar package may introduce other Jars, which is called dependency passing. “Version conflict” occurs when you rely on jar packages of different versions to be passed or imported.

  • The parent project version is locked

    Version locking only specifies the version of the dependency and does not import the dependency.

<properties>&emsp; &emsp;<spring.version>4.2.4. RELEASE</spring.version>
</properties>.<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-bean</artifactId>
            <version>${spring.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>
Copy the code

  • Priority of dependency (secondary)

  • Exclude dependencies (not common, Baidu can)

    ​

    The impact of dependency scope on dependency delivery

pom.xml

/ / TODO: to be continued