What is the difference between Maven Package and Maven Install?

What maven commands do you use most often?

What is <dependencyManagement>?

Have you used any other build tools? How is it different from Maven?

If you’re a maven maven, go ahead and write some code

GitHub JavaEgg, N line Internet development essential skills weapon spectrum

1. What is Maven:

Maven is the only automated build tool maintained by the Apache Software Foundation, focusing on project building and dependency management for the Java platform.

Maven is a software project management tool based on the Project Object Model (POM) that manages the build, reporting, and documentation of a project with a short piece of descriptive information.

2. What Maven does:

  • Add third-party JAR packages
  • Dependencies between Jars: Maven automatically imports all other JARS that the current JAR depends on for us
  • Obtaining third-party JAR packages: Maven provides a fully standardized JAR package management system. Simply rely on a jar package in the project in a coordinate manner and Maven automatically downloads it from the central repository to the local repository
  • Divide the project into engineering modules
  • Build the project (package, compile, etc.)

3. Main links of project construction:

  • Clean: Deletes previous compilation results in preparation for recompilation
  • Compile: Java source programs are compiled into bytecode files
  • Test: Test the key points in the project to ensure the correctness of the key points in the iterative development process
  • Report: Record and present test results in a standard format after each test
  • Package: Encapsulate a project containing many files into a compressed file for installation or deployment. The Java project corresponds to the JAR package, and the Web project corresponds to the WAR package.
  • Install: In the Maven environment, this refers specifically to the installation of packaged results — JAR packages or war packages — into the local repository.
  • Deploy: Deploy the packaged results to a remote repository or deploy the WAR package to run on a server.

4. Common Maven commands

  • MVN -version/-v — Displays the version information
  • MVN clean — Clears generated files
  • MVN compile — compile
  • MVN test — Compile and test
  • MVN Package – Generate target directory, compile and test code, generate test report, generate JAR/WAR file
  • MVN Site – A site that generates project-related information
  • MVN clean compile – indicates that the code is compiled into the target folder after the clean is run
  • MVN Clean Package — Runs cleaning and packaging
  • MVN Clean Install – Runs clean and install, which installs the package into the local repository so that other projects can call it
  • MVN Clean deploy — Runs cleaning and publishing

5.Maven core concepts

Maven’s ability to automate builds is closely related to its internals. Here we look at nine of Maven’s core concepts and see how Maven can automate builds

  • POM
  • The convention directory structure
  • coordinates
  • Dependency management
  • Warehouse management
  • The life cycle
  • Plug-ins and targets
  • inheritance
  • The aggregation

Maven’s core program defines only abstract life cycles, and the specific operations are performed by Maven plug-ins. However, Maven plugins are not included in Maven’s core program and need to be downloaded from the Internet for the first time. The downloaded plug-ins are saved to a local repository. The default location of the local repository is ~.m2\repository.

5.1. Maven convention project directory:

A commonly accepted view in Java development: Convention > Configuration > code (problems solved by configuration should not be coded, and those solved by convention should not be configured)

5.2. The POM

The Project Object Model. Encapsulate Java project-related information as objects that are easy to manipulate and manage.

Core configuration of Maven project.

5.3 coordinates

  • Maven coordinates uniquely identify a Maven project in Maven’s repository using the following three vectors.
    • Groupid: domain name of a company or organization in reverse order + current project name
    • ArtifactId: module name of the current project
    • Version: indicates the version of the current module
  <groupId>net.lazyegg.maven</groupId>
  <artifactId>Hello</artifactId>
  <version>0.0.1 - the SNAPSHOT</version>
Copy the code

  • How do I find jar packages in the repository by coordinates?

    • Let’s connect the three vectors gav
    Net. Lazyegg. Maven + Hello + 0.0.1 - the SNAPSHOTCopy the code

    • Use the concatenated string as a directory structure to look up in the repository

      Net/lazyegg/maven/Hello / 0.0.1 – the SNAPSHOT/Hello – 0.0.1 – the SNAPSHOT. The jar

※ Note: Our own Maven project must perform installation before entering the repository. The installation command is MVN install

5.4. Rely on

The most critical part of Maven is the dependency management function that we use most of Maven. To understand and master Maven dependency management, we need to solve the following questions:

What is the purpose of dependence

When the A jar package uses some classes in the B Jar package, A becomes dependent on B. This is A conceptual description. So how do we introduce a jar package we need in a dependent way in our project? The answer is simple: use the Dependency tag to specify the coordinates of the dependent JAR packages.

<dependency>
    <groupId>net.lazyegg.maven</groupId>
    <artifactId>Hello</artifactId>
    <version>0.0.1 - the SNAPSHOT</version>
    <scope>compile</scope>            
</dependency>
Copy the code
② The scope of dependence

Sometimes the dependency information contains a scope setting in addition to the coordinates of the target JAR package, which is the scope of the dependency. Compile, test, provided (compile, test, provided); compile, test, provided (runtime, system);

  • Compile: The default range is valid for both compile and test runs

  • Provided: Is available at compile and test time

  • Runtime: valid at test and runtime

  • Test: This parameter is valid only during the test

  • System: valid during compilation and testing, associated with the local system and poor portability

  • Commonly used dependency scope validity summary

compile test provided
The main program Square root x Square root
The test program Square root Square root Square root
Participate in the deployment Square root x x
③ Transitivity of dependence

A depends on B, B depends on C. Can A use C? It depends on whether B depends on C, if it is available, otherwise it is not available.

(4) the exclusion of dependence

If we introduce A dependency on A in the current project, and A depends on B, Maven will automatically introduce A dependency on B into the current project, but in rare cases B may be an unstable version or have adverse effects on the current project. In this case we can exclude B when we introduce A.

<dependency>
    <groupId>net.lazyegg.maven</groupId>
    <artifactId>Hello</artifactId>
    <version>0.0.1 - the SNAPSHOT</version>
    <scope>compile</scope>
    <exclusions>
	<exclusion>
	<groupId>commons-logging</groupId>
	<artifactId>commons-logging</artifactId>
	</exclusion>
	</exclusions>
</dependency>
Copy the code
⑤ Unified management depends on the version of jar packages, it is better to use the same version for a group of JAR packages of the same framework. To facilitate the framework upgrade, the version information of jar packages can be extracted uniformly
  • Uniformly declare the version number
<properties>
	<starfish.spring.version>4.4.1. RELEASE</starfish.spring.version>
	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
Copy the code
  • Reference the previously declared version number
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-core</artifactId>
	<version>${starfish.spring.version}</version>
	<scope>compile</scope>
</dependency>
Copy the code
⑥ Principles of dependency: resolve JAR package conflicts
  • The shortest path is preferred
  • The first to declare the same path takes precedence

Maven Helper, a plugin for Maven Helper, is a plugin for Maven Helper, a plugin for Maven Helper, a plugin for Maven Helper, a plugin for Maven Helper

5.5. The warehouse

  • classification
    • Local repository: Serves all Maven projects on the current local machine
    • Remote warehouse
      • Private server: installed in the current LAN environment, for all Maven projects within the current LAN service
      • Central repository: Located on the Internet, it serves all Maven projects worldwide
      • Mirror image of the central warehouse: set up on all continents to share traffic for the central warehouse. Reduce the pressure on the central warehouse while responding faster to user requests, such as Ali’s mirror
  • File in warehouse
    • The Maven plugin
    • Modules of the project we developed ourselves
    • ※ No matter what kind of jar package in the repository is according to the coordinates of the directory structure, so you can use a unified way to query or rely on, query address: mvnrepository.com/

5.6. Life cycle

5.6.1. What is Maven’s life cycle?

The Maven life cycle defines the order in which the build steps are executed. With this list, Maven can automate the execution of build commands.

Maven has three independent life cycles:

  • Clean Lifecycle does some cleaning prior to the actual build
  • Core parts of a Default Lifecycle build, compile, test, package, install, deploy, etc
  • Site Lifecycle generates project reports, sites, and release sites

They are independent of each other, and you can just call clean to clean the working directory and just call site to generate the site. Of course, you can run all three life cycles directly by running the MVN Clean Install site. Each life cycle consists of a set of phases, and the commands we normally enter on the command line always correspond to a specific Phase. For example, run MVN Clean, which is a phase of the clean lifecycle. There are Clean life cycles and there are Clean phases.

5.6.2. Clean lifecycle

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

5.6.3. Site life cycle

  • 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
  • The site deployment phase and the site deployment phase are often used to generate and publish Maven sites. This is a very powerful feature of Maven, and managers like it. Documents and statistics automatically generated, very nice.

5.6.4. Default Life cycle

The Default life cycle is the most important one in Maven’s life cycle, where most of the work takes place (list some important phases)

  • Validate: Verifies that the project is correct and all required resources are available.
  • Compile: Compile the source code of the project.
  • Test: Test compiled source code using an appropriate unit testing framework. These tests do not need to be packaged and deployed.
  • Package: Packages compiled code into a releasable format, such as JAR, WAR, etc.
  • Integration-test: Process and publish packages to an environment where integration testing can take place, if necessary.
  • Verify: Runs all checks to verify that the package is valid and meets quality standards.
  • Install: Installs packages into maven’s local repository that can be used as dependencies by other projects.
  • Deploy: Executes in an integration or publishing environment and copies the final version of the package to a remote repository so that other developers or projects can share it

5.6.5. Lifecycle and automated builds

When any phase is run, all the preceding phases will be run, for example when we run MVN Install, the code will be compiled, tested, and packaged. This is why Maven automates all parts of the build process. Furthermore, Maven’s plug-in mechanism is completely dependent on Maven’s life cycle, so understanding the life cycle is critical.

5.7. Plug-ins and objectives

  • At its core, Maven defines only an abstract lifecycle, with specific tasks handed over to plug-ins
  • Each plug-in can implement multiple functions, and each function is a plug-in goal
  • Maven’s life cycle is bound to a plugin target to complete a specific build task. For example, compile is a target of the plugin maven-Compiler-plugin. Pre-clean is a goal of the plugin maven-clean-plugin

5.8. Inheritance

  • Why inheritance? Since dependency information that is not in the COMPILE scope cannot be passed in the “dependency chain”, projects that need it can only be configured separately
  • Creating a parent project Creating a parent project is the same as creating a normal Java project. The only thing that needs to be noted is that the packaging method must be set to POM
  • Reference parent project in child project, relative path from current directory to parent project’s POM.xml file
 <parent>
 	<groupId>com.starfish.maven</groupId>
	<artifactId>Parent</artifactId>
	<version>0.0.1 - the SNAPSHOT</version>
	<! -- Relative path of parent project pom.xml file based on current file -->
	<relativePath>../Parent/pom.xml</relativePath>
</parent>
Copy the code

In this case, if the groupId and version of the child project are the same as those of the parent project, they can be deleted.

  • Manage dependencies in the Parent project enclose the Dependencies tag in the Parent project with the dependencyManagement tag
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.9</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement> 
Copy the code

Respecify the required dependencies in the subproject, removing the scope and version number

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
</dependency>
Copy the code

5.9. The aggregation

  • Why use aggregation?

After splitting multiple projects into modules, you need to manually install them in the warehouse one by one to make dependencies take effect. After modifying the source code, you also need to manually clean it one by one. With aggregation, Maven projects can be installed and cleaned up in bulk.

How do I configure aggregation? Use modules/ Module tag combinations in the total aggregation project, specifying the relative path of the module project

<! -- Configure aggregation -->
<modules>
    <! -- Specify the relative path of each subproject -->
    <module>starfish-learn-grpc</module>
    <module>starfish-learn-kafka</module>
    <module>starfish-web-demo</module>
</modules>
Copy the code