1. Module development and design

1.1 Engineering Modules and Module Division

  • In modular development, each module contains only the function class and configuration file corresponding to the current module
  • Spring core configuration is independently made according to different module functions (for example:applicationContext-dao.xml,applicationContext-service.xml…).
  • web.xmlAll of the Spring core configuration files need to be loaded

1.2 Module Aggregation

A project is often composed of multiple modules, in the building, to build commands for each module is a very tedious and error-prone, so Maven aggregation function can be completed for us to build a build commands to complete all modules, so spawned build management module, known as aggregation module.

Aggregation implementation:

1) First create an empty module with a packaging type defined as POM:

<! -- Define the project for module management -->
<packaging>pom</packaging>
Copy the code

2) And define the names of other modules associated with the current module during the build operation:

<! -- List of managed projects -->
<modules>
    <! -- Specific project name -->
    <module>../ssm_pojo</module>
    <module>../ssm_dao</module>
    <module>../ssm_service</module>
    <module>../ssm_controller</module>
</modules>
Copy the code

Note: The final execution order of the modules participating in the aggregation operation is related to the dependencies between the modules, not the configuration order!

1.3 Module Inheritance

Each Maven project module relies on resources such as: In the following figure, the ssm_service module needs to use the Spring-context 5.1.9 resources, while the Ssm_DAO module needs to use the Spring-context 5.2.0 resources. Resources may be duplicate or even conflict due to version incompatibility, which may cause errors.

Therefore, we need to regenerate a new module to manage the resource dependencies of other modules. We only need to write uniform resource dependencies and versions on the new module, and other modules only need to reference without marking the version number.

Inheritance implementation:

1) Define dependency management in the parent project:

<! -- declare dependency management here -->
<dependencyManagement>
    <! -- specific all dependencies -->
    <dependencies>
    	<! - Spring environment - >
        <dependency>
        	<groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.1.9. RELEASE</version>
        </dependency>. .</dependencies>
</dependencyManagement>
Copy the code

2) Declare the coordinate of its parent project and its corresponding position in the sub-project:

<! -- Define the parent project of the project -->
<parent>
    <groupId>com.one</groupId>
    <! -- SSM: parent project module name -->
    <artifactId>ssm</artifactId>
    <version>1.0 the SNAPSHOT</version>
    <! -- Fill in the parent project's POM file -->
    <relativePath>../ssm/pom.xml</relativePath>
</parent>

<! -- definition of the current module -->
<! -- <groupId>com.one</groupId>
<artifactId>ssm</artifactId>
<! -- <version> 1.0-snapshot </version>
<packaging>jar</packaging>
Copy the code

3) Define the dependency relationship in the child project without declaring the dependent version. The version refers to the dependent version in the parent project. If the version needs to be overwritten, directly fill in the required version number:

<dependencies>
    	<! - Spring environment - >
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>.</dependencies>
Copy the code

1.3.1 Inheritable Resources

  • groupId: Formgroup ID, the core element of the project coordinates
  • version: The project version, the core element of the project coordinates
  • description: Describes the project
  • organization: Organizational information about the project
  • inceptionYear: The founding year of the project
  • url: The URL of the project
  • developers: Developer information for the project
  • contributors: Contributors to the project
  • distributionManagement: Deployment configuration of the project
  • issueManagement: Defect tracking system information for the project
  • ciManagement: Continuous integration system information for the project
  • scm: Version control system information for the project
  • malilingLists: Mailing list information for the project
  • properties: Custom Maven properties
  • dependencies: Project dependency configuration
  • dependencyManagement: The dependency management configuration of the project
  • repositories: Warehouse configuration for the project
  • build: includes the project source directory configuration, output directory configuration, plug-in configuration, plug-in management configuration, etc
  • reporting: including the project report output directory configuration, report plug-in configuration and so on

1.4 Aggregation & Inheritance summary

1.4.1 role

  • Aggregation: Build projects quickly
  • Inheritance: Quick configuration

1.4.2 similarities

  • Aggregation and inheritancepom.xmlThe file packaging mode ispom, you can make both relationships into the same POM file
  • Aggregation and inheritance are both design modules and have no actual module content

1.4.3 differences

  • Aggregation is the configuration of relationships in the current module, and the aggregation is aware of which modules are participating in the aggregation
  • Inheritance is the configuration of relationships in submodules, and modules cannot sense which submodules inherit from them

2. Attribute definition and use

2.1 Custom Attributes

1) Function: Equivalent to defining variables and facilitating unified maintenance

2) Definition:

<! -- Define custom properties -->
<properties>
	<spring.version>5.1.9. RELEASE</spring.version>
    <junit.version>4.12</junit.version>
</properties>
Copy the code

3.

<dependency>
	<groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>${spring.version}</version>
</dependency>
Copy the code

2.2 Built-in Properties

1) Function: Use the built-in attributes defined by Maven for quick configuration

2.

${basedir} ${version} ${... }Copy the code

2.3 Setting attributes

1) Function: Use the tag attributes in Maven configuration file setting. XML for dynamic configuration

2.

${settings.localRepository}
Copy the code

2.4 Java system properties

1) Function: Read Java system variables

2) Query method of system properties:

mvn help:system
Copy the code

3.

${user.home}
Copy the code

2.5 Environment variable attributes

1) Function: Use the tag attributes in Maven configuration file setting. XML for dynamic configuration

2) Environment variable attribute query mode:

mvn help:system
Copy the code

3.

${env.JAVA_HOME}
Copy the code

3. Version management

3.1 Project Version Differences

SNAPSHOT: indicates the SNAPSHOT version

  • In the process of project development, in order to facilitate the cooperation of team members, solve the problem of interdependence and constant update among modules, the developer builds each module, and the output temporary version is called snapshot version (test phase version).
  • The snapshot version will be updated as development progresses

RELEASE: Indicates the RELEASE version

  • After the project development reaches the phase milestone, a relatively stable version is released to the team outside. The component file corresponding to this version is stable, and the content of the current release version will not be changed even if the subsequent development of the function is carried out. This version is called release version

3.2 Project Version Number Convention

Contract specification

  • < Major >.< Minor >.< Incremental >.< Milestone >
  • Major release: represents significant architectural changes to a project, such as Spring5 versus Spring4 iterations
  • Minor release: Indicates major feature additions and changes, or a comprehensive and systematic fix of bugs
  • Incremental version: Indicates a significant bug fix
  • Milestone version: Indicates the milestone (within the version) of a version. Such a release is relatively unstable compared to the next official release and needs more testing

specification

  • 5.1.9. RELEASE

4. Configure resources

Not only do we need to manage the properties in the POM.xml file, for example, but we also need to consider the Properties file in resources…

To manage resources in a unified manner, configure resources in the POM. XML file.

1) Set the configuration file path in the pom.xml file

<build>
	<resources>
    	<! -- set the location directory corresponding to the configuration file, support dynamic setting path using properties -->
        <directory>${project/basedir}src/main/resources</directory>
        <! -- Enable resource load filtering for configuration files -->
        <filtering>true</filtering>
    </resources>
</build>
Copy the code

2) Enable the poM attribute filtering function

<properties>
	<jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>
    <jdbc.url>com.mysql.jdbc.Driver</jdbc.url>
    <jdbc.username>com.mysql.jdbc.Driver</jdbc.username>
    <jdbc.password>com.mysql.jdbc.Driver</jdbc.password>
</properties>
Copy the code

3) Reference poM attributes in the ${attribute name} format

5. Multi-environment development configuration

When we develop a component, the configuration is loaded differently in different environments, such as the following:

Load configuration A in production, configuration B in development, and configuration C in test…

We can’t keep changing the configuration files as the environment changes, so we need to be compatible with multiple environments!

Multienvironment configuration of pom. XML file:

<! -- Create multiple environments -->
<profiles>
    <! -- Define the specific environment: production environment -->
    <profile>
    	<! -- define the unique name of the environment -->
        <id>pro_env</id>
        <! -- Define context-specific attribute values -->
        <properties>
        	<jdbc.url>JDBC: mysql: / / 127.1.1.1:3306 / ssm_db</jdbc.url>
        </properties>
        <! -- Set default startup -->
        <activation>
        	<activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <! -- Define the specific environment: Development environment -->
    <profile>
        <id>dev_env</id>.</profile>
</profiles>
Copy the code

Load the specified environment:

  • Call format
MVN directive -p Environment definition IDCopy the code
  • sample
mvn install -P pro_env
Copy the code

6. Skip tests

6.1 Application Scenarios of Skipping tests

  • The overall module function is not developed
  • A function in the module has not been developed
  • Updating and debugging a single function causes other functions to fail
  • Rapid packaging
  • .

6.2 Three Ways to Skip tests

6.2.1 Command To Skip tests

  • The command
The MVN instruction -d skipTestsCopy the code
  • Note: the execution of the instruction life cycle must include testing!

6.2.2 GUI Operations Skip tests

6.2.3 Configuration Skip tests

  1. Skip all tests
<plugins>
	<plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.1</version>
        <configuration>
            <! -- Set to skip all tests -->
        	<skipTests>true</skipTests>
        </configuration>
    </plugin>
</plugins>
Copy the code
  1. Skip some tests
<plugins>
	<plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.1</version>
        <configuration>
            <! -- Contains the specified test case -->
            <includes>
            	<include>**/UserServiceTest.java</include>
            </includes>
            <! -- Exclude specified test cases -->
            <excludes>
            	<exclude>**/AccountServiceTest.java</exclude>
            </excludes>
        </configuration>
    </plugin>
</plugins>
Copy the code

7. Private servers

The private server plays a very important role in the modular cooperative development

7.1 the Nexus

Nexus is a private Maven server from Sonatype

Download address: help.sonatype.com/repomanager…

7.2 Installing, Starting, and Configuring the Nexus

  • Start the server (command line start)
nexus.exe /run nexus
Copy the code
  • Access server (default port: 8081)
http://localhost:8081
Copy the code
  • Example Modify basic configuration information
    • In the installation pathetcIn the directorynexus-default.propertiesThe file contains basic Nexus configuration information, such as the default access port
  • Example Modify server configuration information
    • In the installation pathbinIn the directorynexus.vmoptionsThe file contains the configuration information related to the startup of the Nexus server, for example, memory space by default

7.3 Obtaining Private Server Resources

7.4 Warehouse Classification

  • The host warehousehosted
    • Stores resources that cannot be obtained from the central repository
      • Independent research and development
      • Third-party non-open source projects
  • The agent warehouseproxy
    • Proxy remote repositories that access other public repositories, such as central repositories, through nexus
  • The warehouse groupgroup
    • Group several warehouses together to simplify configuration
    • The warehouse group cannot hold resources and is a design warehouse

7.5 Uploading Resources

When uploading resources, you need to provide the following information:

  • Save location (host repository)
  • Resource file
  • The corresponding coordinates

7.6 Uploading and Downloading resources in the IDEA Environment

7.7 Accessing private Servers (Accessing Private Servers from a Local Repository)

  • Configure local repository access to private servers (setting.xml)
<servers>
    <server>
    	<id>one-release</id>
        <username>admin</username>
        <password>123456</password>
    </server>
    <server>
    	<id>one-snapshots</id>
        <username>admin</username>
        <password>123456</password>
    </server>
</servers>
Copy the code
  • Configuring local repository resource sources (setting.xml)
<mirrors>
    <mirror>
        <id>nexus-one</id>
        <mirrorOf>*</mirrorOf>
        <url>http://localhost:8081/repository/maven-public/</url>
    </mirror>
</mirrors>
Copy the code

7.8 Configuring Access to private Servers (Project Access to Private Servers)

  • Configure the current project to access the private server upload resources to save location (POM.xml)
<distributionManagement>
    <repository>
        <id>one-release</id>
        <url>http://localhost:8081/repository/one-release/</url>
    </repository>
    <snapshotRepository>
        <id>one-snapshots</id>
        <url>http://localhost:8081/repository/one-snapshots/</url>
    </snapshotRepository>
</distributionManagement>
Copy the code
  • A command to publish resources to a private server
mvn deploy
Copy the code

At best, this is just the basics of Maven’s progression, or far from it…

For more information about Maven, check out more blogs

If this article has helped you, please give a thumbs-up to support ow 🔥