Introduction
Rather than simply introducing MAVEN concepts, this article introduces a specific maven project file planning
This plan may be suitable for the development of more complex business, which has the need of distributed and service .
This plan solves the problem of project confusion due to the distributed and service requirements.
At the same time, the program can solve the problem of repeating "wheels" in project development. These "wheels" are mainly derived from two categories:
- The code repeats the "wheel", so to extract the project leads to a further increase in the number of projects.
- Manually build repetitive "wheels" of projects, build more complex relationships, and increase error rates, so automate builds through a configuration-and contract-based approach.
Other not more than repeat, directly on the dry.
the actual planning diagram
Common responsibilities for all parent
- Build all the projects that are aggregated underneath it. A contract is a project that aggregates only its subdirectories and cannot be aggregated across directories
- Manages the common nature of the artifacts that it aggregates, namely the existence of inheritance relationships. These common features are extracted from the project itself that it aggregates. Convention this inheritance and aggregation use the same project.
- A version that relies on other projects or jars is used in a unified management project that it aggregates. The aggregated project only allows dependencies on its underlying projects. Specific layering, see the hierarchical dependencies below
We-parent's Responsibilities
Responsibilities: Build all the projects you need to publish in one click.
General Features:
- All projects are initially dependent on these jar packages, for example: testng (unit test related), H2 (unit test related), Easymock (unit test related), Lombok (automatically generated setter and getter based on annotations)
- Additional features for all projects, such as: Unit Test Plug-in
- Project Release Management, for example: private maven Configuration
We-core-parent's Responsibilities
Responsibilities: The projects it aggregates are not related to the business and only provide the basic capabilities. Abbreviation: Core project. For example: Database persistence, Redis cache capability, HTTP encapsulation capabilities, generic tooling capabilities, and more.
General Features:
- Javadoc plug-in for generating Javadoc
We-base-parent's Responsibilities
Responsibility: The project it aggregates has and can only represent a real and independent core entity corresponding to the business, referred to as: the base project.
Concept Explanation:
- Real existence: that can be carried by a concrete objective object. For example: Users, courses, questions
- Stand-alone: not dependent on any other business, where it can be presented on its own. For example: where the questions are placed can be displayed, and the course can be presented anywhere.
- Core entity: A business service can be realized by an entity, at most, the field attributes are more, the implementation is more complex. For better implementation, we can split this entity into a lot. However, no matter how many entities are split, there is always one that is most important, and the other entities have no meaning without the entity. For example, questions are abstracted into question entities and answer entities. If there is no question, the answer is not the meaning of existence. So the question is the core entity.
General Features: No
We-business-parent's Responsibilities
Responsibility: The project it aggregates must be a "shared" business process, referred to as: a businesses project. It may be necessary to reference the base service during this process. It does not have a real existence and can exist independently of the core entity
Concept Explanation:
Sharing: In product planning, the service may be used by multiple products, which is shared.
General Features:
- A unified reference database persistence capability, which is a database implementation project.
We-web-parent's Responsibilities
Responsibilities: The projects it aggregates can provide services to users over the Internet, in product planning its own unique non-shared business, abbreviated as: Web projects.
General Features:
- Unified reference HTTP parsing capability. Parsing and rendering of HTTP.
- Monitoring related
Hierarchical dependency Relationships
In addition to We-parent, each parent's corresponding responsibility is a project layering. These items are layered from top to bottom in relation to the.
How to use
Hypothesis: Now a product draft (PRD, prototype or final requirement)
Use the following steps:
- Analysis, whether the product to provide users with independent services, not affected by other products. If you want, create a new Web project.
- Analysis, this product is not what business is ready to be used by other products, that is, the interface of other products is not reflected in this product.
- If there is, analyzing these common businesses, there is no process involved, that is, its business in combining other existing base projects. If so, create a new Business Project
- Analysis, this product can exist independently, do not rely on any other services business. If so, create a new base project.
- When implementing these encodings, create a new core project if you encounter some business-agnostic and only provide the capabilities.
In summary: The analysis is based on layering, from top to bottom. Analyze the responsibilities of each layer and create a new one if one is available. Each project must be built under the corresponding parent.
Maven project file planning based on distributed and service
