“This article has participated in the call for good writing activities, click to view: the back end, the big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

preface

Copy and paste frequently used code from previous projects every time you create a new project? When building the project architecture, copy the utility classes and configuration classes from the various old projects? This article will largely let you avoid using the bad street martial arts – CV dafa.

The main goal of this article is to ensure the smooth completion of the process, so the examples used in this article are the simplest; There are a lot of details to build maven server, but that will be in the next article. The next article I still look forward to, because there is a very interesting knowledge point.

Building a Maven repository

1. Log in to github and create a maven-test repository, as shown in the figure below. Set the permission to public, otherwise you will not be able to import dependencies later.

It is best to check “Add a README file” at creation time because you cannot get the repository address without checking it (you can test it yourself). After creating it, I get the warehouse address

[[email protected]](mailto:[email protected]):xinmachong/maven-test.git
Copy the code

This address will be used later.

Creating a New Maven Project

With a repository for code submission, it’s time to knock code.

To create a Maven project using IDEA, I used to give the front-end interface response structure as follows:

{
		"code":200."msg":"success"."data":"anything struct"
}
Copy the code

So I created a response body in the project that I use in my daily projects, with the goal that I wouldn’t have to write this code again for any new projects.

The main goal of this article is to make sure that the process runs smoothly, as mentioned above, so that’s all I have to say about my Maven project right now. The next step is to release the project.

Publish the project

Initialize the local repository with Git and add the remote Git repository address (the repository address obtained above)

Start by creating a new folder in any location, such as G:\GitHub\maven-test; Then use git to execute the following command:

git init
git remote add origin [[email protected]](mailto:[email protected]):xinmachong/maven-test.git
Copy the code

Use MVN deploy to publish artifects to the local Git repository you just created

mvn deploy -DaltDeploymentRepository=${distribute_id}::default::file:${git_repo_path}
Copy the code

Among them, the corresponding pom file distributionManagement {distribute_id} / repository/id need to fill in content, can fill in, but here need to use the id of the consistent and articles behind. ${git_repo_path} = G:\GitHub\maven-test

Git and the self-named packag-com folder. As shown below:

Any Artifects that need to be released are submitted to the local Git repository and pushed to the master branch

git add com/*
git commit -m "deploy maven-test"
git push origin master
Copy the code

If the publication is successful, you can see the submission on Github as follows:

Introduce dependencies and test

Now that everything is done, it’s time to validate the results. Create a new Spring Boot project and add a personal repository to the pop.xml file where the id is xinmachong of ${distribute_id} and the url is raw.github.com/username/.

<repositories>
    <repository>
        <id>xinmachong</id>
        <url>https://raw.github.com/xinmachong/maven-test/master</url>
    </repository>
</repositories>
Copy the code

Reintroduce dependencies

<dependencies>
    <dependency>
        <groupId>com.xinmachong</groupId>
        <artifactId>maven-test</artifactId>
        <version>1.0 the SNAPSHOT</version>
    </dependency>
</dependencies>
Copy the code

This information can be found in maven-metadata.xml, as shown below:

Finally, write a test interface in the control layer

As you can see from the image above, I didn’t create the object ApiResponse in the project, but I can just new it. From the import com. Xinmachong. Response. ApiResponse; As you can see, the object in the Maven project was successfully called. In the future, all new projects don’t have to duplicate the wheels of the interface response body, just introduce their own dependencies.

I just wanted to ask, is it a dick?

All right, I’m just kidding. The simple examples I used mask many of the pitfalls of setting up your own Maven repository. If we were using JWT for every project now, it would be natural to package the functionality of JWT further, but the signatures and expiration dates in JWT are written in the configuration file. In addition, JWT will intercept all unapproved interfaces for token authentication, so I would like to ask the following two questions:

JWT: JWT: JWT: JWT: JWT: JWT Just write @value (‘ $attribute ‘) in your Maven project, and the new Spring Boot project will automatically inject it into the dependency package for you? Head iron can try, anyway my head bag has not detumescent.

2. After the interceptor is written and packaged, how does it automatically take effect in a new project? Write it in your Maven project, publish it to Github, and automatically intercept it when you introduce dependencies? Such a simple and crude will not work, the first iron can try.

The real solution is to read the next article…