Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Is Maven suitable for managing a common code base?

2025-03-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

The main content of this article is "is Maven suitable for managing public code base", interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "is Maven suitable for managing the public code base?"

1. Common code base

In any project, we will inevitably have a common code base, which may contain some tool classes or entity classes for use by other projects.

The usual practice is to upload the public code base to the company's private server, and then everyone can add dependencies to the project. I believe many friends have played this way.

But I don't know if you have ever thought that this approach actually has a drawback, which is that it is not suitable for fast iterative projects.

In a fast iterative project, common changes very frequently, which means that developers have to constantly package and upload common, and others keep changing the referenced common version number.

In traditional monolithic applications, there may not be too many team members and common changes are not frequent, so the disadvantage of using Maven to manage common code blocks is not obvious.

At present, the popular micro-service architecture is suitable for large legions, and there are a large number of micro-services. In micro-service projects, there are dozens or hundreds of micro-services. In order to solve the problem of serialization when calling between microservices, we may draw entity classes into a public common, and each microservice can modify the common according to its own needs. Even if each microservice modifies the common once a day and reflects it on the common, it changes day and night, while other microservices have to constantly change the version number in order to follow this change day and night.

In this case, it is obviously not appropriate to use Maven to continue to manage common, because it means that you have to keep packing, and all microservices have to constantly change the referenced common version number.

"

To prevent criticism, Songge has to add that the above situation is common in fast-iterative microservice projects, especially the larger the team and the more microservices, the more obvious the disadvantage of Maven managing common code blocks. In traditional monomer applications, it may not be easy to feel the problem.

As you can see from the above description of Song GE, Maven actually focuses more on package dependency management. Although it can synchronize common code in different projects, it cannot synchronize in both directions (the so-called bi-directional synchronization means that updates of common in various micro-services are automatically synchronized to common library, and updates of common library can also be automatically synchronized to various micro-services). Maven is more suitable for situations where the common code base is relatively stable.

two。 Solution

If the common code base is constantly changing and Maven is not particularly convenient, do we have any other solutions?

2.1 Git Subtree

Git Subtree is a solution for managing sub-projects officially given by Git. Before Git Subtree, the official solution was Git Submodule, but starting from Git1.5.2, Git added and recommended to use this feature to manage sub-projects. As long as the locally installed version of Git is greater than or equal to 1.5.2, you can directly use Git Subtree.

Although Git Subtree does not have the function of relying on management, it is very handy when dealing with a fast-replacing common code base, and it can synchronize in both directions!

2.2 specific applications

First of all, suppose I have a project called vmall,vmall, a microservice project that contains a lot of microservices, as well as a rapidly iterating common code block vmall-common (note that vmall and vmall-common belong to two different repositories).

I have submitted vmall-common on GitHub at https://github.com/lenve/vmall-common.

Now I want to reference vmall-common in the vmall project. What can I do? Execute the following code in the vmall repository:

Git subtree add-prefix=vmall-common https://github.com/lenve/vmall-common.git master-squash

The final-- squash parameter means that history information is not pulled, but only a commit message is generated, which is an optional parameter and can be left unadded. After the execution of this command, you can see vmall-common in the vmall project, and vmall-common will exist as a normal folder, whatever happens.

At this time, we can develop normally.

Let's say that we modified the vmall-common during the development process, and at this time, in the vmall repository, we can submit the vmall-common to its own repository with the following command (first submit the changes in vmall to the remote warehouse, then execute the following code):

Git subtree push-- prefix=vmall-common https://github.com/lenve/vmall-common.git master

If you are submitting this change in vmall-common 's own warehouse, it is a normal Git submit order, and I don't need to say much about this.

When the code in vmall-common changes, other microservices can update the code with the following instructions:

Git subtree pull-prefix=vmall-common https://github.com/lenve/vmall-common.git master-squash

These three instructions can basically handle most of the daily operations, but it is inconvenient to enter a long address each time. We can give the address an alias:

Git remote add-f vmall-common https://github.com/lenve/vmall-common.git

In this way, the top three commands can be simplified:

Git subtree add-prefix=vmall-common vmall-common master-squash

Git subtree pull-prefix=vmall-common vmall-common master-squash

Git subtree push-prefix=vmall-common vmall-common master so far, I believe you have a deeper understanding of "is Maven suitable for managing a public code base?" you might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report