maven multi-module structure engineering practice (a)

A root pom create a separate file, root-pom, pom file only one project file as follows:

1. each jar dependent version, i.e., the content dependencyManagement

2. build the resource requirements and testResource file format and destination folder

3. pluginManagement, specifies the version of each plug-in

4. distributionManagement, the nexus predetermined PW

 

II. Create a project file project MyProject, it consists of three modules

1. myproject-module, mainly used to model and enum class information is stored needs to be referenced by other services

2. myproject-api, mainly used to store the service of the service interfaces

3. myproject-service, mainly used to implement the services provided by the project is the actual realization

So, I'm in this project, get four pom file, artifactId were myproject myproject-module myprojec-api myprojec-service,

 

pom inheritance:

Outermost myproject inherit root-pom, and declare its version number in the project myproject in, myproject-module myprojec-api myprojec-service three sub-modules, the parent pom is myproject, inherit their groupId, but artifactId as separate modules all , inherited from the parent pom sub-module version number, sub-module is used to depend on the specific jar and profile as well as a variety of plug-ins are inherited from the parent pom version dependent.

 

 

Specific items used as a spring-cloud services management framework based on which part feign api implemented, achieve the outgoing separate jar, leakage implement interfaces and services, service interfaces implemented in predetermined api, module defined in each exposed outside definitions of categories.

The reason to make more engineering structures:

1. unified version of each jar, because engineering practice, a service will be integrated more and api module, each module is inconsistent if the jar in existence since version, the final version will have a dependency problems, particularly in certain dependent jar security problems, the need for time version upgrade.

2. The original dependency structure, api alone inherit pom has feign property, service and independent inheritance pom have db mvc and eureka-client property, and each pom ultimately inherit from a specified root and various versions of the actual dependency pom, pom although simplifying the child in a variety of configurations, but the resulting version depends on the intricacies, coupled with the relations maven pom inheritance and release, resulting in cumbersome upgrade version, and there is a potential conflict jar.

3. api module and the version with the update service interface is updated due, so each sub-module inherits the version number of the project, if the interface updates occur only need to update to version outgoing version of the project in pom.

 

 

 

 

 

Published 20 original articles · won praise 0 · views 10000 +

Guess you like

Origin blog.csdn.net/u011248560/article/details/100086275