Turn "maven Combat (eight)---module division

This blog post originates from: http://blog.csdn.net/liutengteng130/article/details/47000217 thanks!

in order to prevent transitive dependencies, we try to use a direct-dependent approach between the various modules. This article describes the multi-module development, We have done Maven project know, our project is generally sub-module, each module will correspond to a pom.xml file, between them through inheritance and aggregation (also multiprocessing module, Multi-module) are interrelated.

let's think of another way of thinking, so we can use a module for a project. This is very convenient to open, simple and clear, then do it, next we analyze.

Let's say we have a project where the entire project builds a war package, and each layer is placed in its own packages . As follows:

Itoo-exam

Com.tgb.itoo.exam.dao----- is responsible for interacting with the database, encapsulating the interaction classes of hibernate

Com.tgb.itoo.exam.service---- is responsible for handling business logic, putting service interfaces and their implementation classes .

Com.tgb.itoo.exam.web------- responsible for interaction with the client, mainly put Action/controller, JSP and so on

Com.tgb.itoo.exam.util-------- Tool class

So as our project expands and theMaven project gets bigger and larger, there are a couple of issues that you'll encounter:

1, first build the entire project time is getting longer, although you have been working on the web tier, but you have to build the entire project

2, modular embodiment, if we are only responsible for maintaining a module, because all of our modules are in a war package, then we can arbitrarily modify other modules (permissions control), resulting in version management confusion, conflict. At the same time because the module too much, too big, not good maintenance.

Many people are modifying the war package at the same time , which will cause the work to fail smoothly.

3,pom.xml can be inherited, reused, but if we create a new project, can only rely on the War package, then the war package will be related to the foreground of the things to rely on, resulting in project management confusion.

Such management is chaotic and does not follow a design pattern principle: "High cohesion, low coupling". Instead, inside the code, everything is coupled together. So we need to divide the module.

In addition, with the rapid development of technology and a variety of user requirements for software more and more high, the software itself becomes more and more complex, designers began to use a variety of ways to develop, so there is our layered architecture, layered modules to improve the clarity and reuse of code. The high cohesion and low coupling are realized in the system.

Actually the package structure of our project:

Itoo-root (pom.xml Pom bag )

Itoo-base-parent (pom.xml Pom bag )

Itoo-base(pom.xmljar bag)

Itoo-tool(pom.xmljar bag)

Itoo-exam-parent (pom.xml Pom bag )

Itoo-exam-api (pom.xml jar package )

Itoo-exam-student-core (pom.xml jar package )

Itoo-exam-student-web (Pom.xml War pack )

Itoo-exam-student-ear (pom.xml ear pack )

As in the diagram above, the POM package is full of the parent project, which is used to manage the child project jar packages. Many sub-projects are aggregated within the parent.

Dependency of the module:

Itoo-base--->itoo-tool

Itoo-exam-api-->itoo-base

Itoo-exam-student-core--->itoo-exam-api

Itoo-exam-student-web--->itoo-exam-api

The benefits of modularity

1, convenient reuse, when we develop a teacher line, we only need to refer to Itoo-base,itoo-exam-api, these packages are reused, called our platform reuse base Class library for all projects to use. This is one of the most important purposes of modularity.

2, divided the module, the dependencies between the package is very clear, the package version management is very clear, do not have to a chaotic Pom to modify their own configuration.

3, flexibility. such as our public jar package,Itoo-base,itoo-tool,itoo-exam-api and so on these jar package, we do not need to be the source code, only need to deploy to Nexus, and other people can download it from the Nexus . The code is maintainable, extensible, and ensures project independence and integrity.

4,build project, only need to build their own needs of the project, not only save time and structure clear.

5, the previous article wrote dependencymanagement and dependencies, theparent project manages the Jar package version. Makes the test version of the entire project consistent with the release version.

The use of modular configuration, strong reusability, to prevent the Pom becomes too large, easy to build; for project management more convenient, each module is independent, abstract a parent class to manage the third-party jar version, developers only need to develop their own lines, The rest is not in control, flexible; Based on this basis we can also do distributed.

As mentioned above, we use the parent project to aggregate the subproject and the child project to inherit the parent project. Next blog We continue to introduce the aggregation and inheritance of Maven modules.

Go maven Combat (eight)---module division