Maven should be used a lot on a daily basis, after all, we need to package and launch, but when I first graduated, there was no such concept.

We certainly know that Maven can manage our projects, but we often use Maven only to import various dependencies while learning.

We must have known that Maven had a repository, and then we configured a domestic Maven repository to make jar packages download faster.

We might use Maven to compile our own projects, type the package locally, and then start the project locally. If we have a machine server, after finishing the package, we will manually upload the local WAR package to our own server to start.

We probably know that Maven can configure its own repository (private repository) and probably build it, but how many people publish their JARS to private repositories?

When we go to the company, the company usually has its own private warehouse. The system we write may be used by various teams, so we will type the written package to the private warehouse. There are only a few Maven commands that are commonly used:

1. Compile 2. Compile MVNtestMVN clean 4, MVN pakage 5, MVN install 6, MVN deploy 7, MVN versionssetMVN dependency:tree MVN dependency:tree MVN dependency:tree MVN dependency:tree -dmaven.test.skip =true
-Dmaven.javadoc.skip=trueCopy the code

The difference between package, install, and deploy is as follows:

• The package command does project compilation, unit testing, and packaging, but does not deploy executable JARS (war packages or other forms of packages) to local maven repositories or remote Maven private repositories
• The install command completes the project compilation, unit testing, packaging, and deployment of executable JARS (war packages or other types of packages) to the local Maven repository, but not to the remote Maven private repository
• The deploy command completes project compilation, unit testing, packaging, and deployment of prepared executable JARS (war packages or other forms) to local maven repositories and remote Maven private repositories

We use the parent project’s POM.xml to manage the version of our jar package. We reference the parent project’s version in the child Module.

Don’t foolishly write the versions of various JAR packages under the child Module, although jar packages can be imported, but this is not standard.

Here’s a quick look at some of the most commonly used commands.

Skip =true MVN compile-dmaven.test. skip=true MVN compile-dmaven.test. skip=true MVN compile-dmaven.test. skip=true

MVN package-dmaven.test. skip=true

Three crooked an indescribable experience

Recently, we have been integrating the system in three ways, integrating some scattered systems into one system, so there will be multiple modules in one system. Previous projects also had multiple modules, just not as many as now, as shown in the figure below

Dev /local/online/pre (dev/local/online/pre) Obviously, the configuration should be different for our different environments.

It should be easy to understand how the server configuration on our line and the configuration of the test environment can be the same, so the configuration of each environment is separate.

In order to merge, I merged some systems into the parent project. So I will create a new Module under the parent project and copy the code into it. Obviously, each project may have its own configuration, and the configuration is also context-specific.

For example, the following figure (sanwai.name configuration is read by the configuration in each environment) :

I have the value of sanwai.name written in the configuration file for each environment

By the time I was done, I found that the service would not start and I had not read the value I had configured in dev/local/pre/online. I doubt it. I configured it.

I have already written the property-placeholder of Spring, and there are no problems with the path. You can “click” to jump to the corresponding configuration file locally. What a deal

<context:property-placeholder
   ignore-unresolvable="true" ignore-resource-not-found="true"
   location="classpath*:core-config.properties" />Copy the code

So I spent a long time looking at my property-placeholder position to see if there was a problem, if I was using the position incorrectly.

Finally, I could not bear it, and asked my colleague if he had ever encountered this pit. Then my colleague told me that reading configuration by environment is not a function of Spring, but Maven

Me: ？？？？ I did a little Intranet search, and it was. At first glance, Maven’s profile function is used.

Later in the POM file specified to read the corresponding configuration file path, it is ok.

<build>
   <resources>
      <resource>
         <directory>src/main/resources</directory>
         <filtering>true</filtering><! </resources> </resources> </build>Copy the code

The idea is to specify different environments at packaging time to generate a correct configuration file.

mvn clean package -DskipTests -Ptest// The specified value istestThe environmentCopy the code

So it makes sense that if I’ve ever published code, I should know there’s such a thing.

We have our own publishing system that hides a lot of details (both Git and Maven are hiding a lot of details). There is no need to type commands to create Git branches, merge master branches, or type maven commands to package.

Finally, a Maven field document is recommended here

This book is suitable for all Java programmers. Since automated builds, dependency management, and other issues are not unique to the Java world, non-Java programmers can benefit from this book as well. Whether you have never touched Maven, have been using Meven for a long time, or want to expand Maven, you will get valuable advice from this book.

Second, this book is also a good read for project managers, as it will help you manage Your Java projects in a more disciplined and efficient way.

Chapter 1 gives a brief introduction to Maven, using examples familiar to programmers about what Maven is. What Maven needs. All readers are advised to read it to get a sense of the big picture.

Chapters 2-3 are a personal introduction to Maven, which is helpful for beginners and can be skipped if you are already familiar with Maven.

Chapter 4 introduces the background case used in this book, which will be the basis for many of the chapters that follow, so readers are advised to skim it at least once.

Chapters 5-8 provide an in-depth overview of Maven’s core concepts, including coordinates, dependencies, and repositories. Life cycle, plug-ins, inheritance and multi-module aggregation, etc., each knowledge point is accompanied by practical cases, which are recommended for careful reading.

Chapter 9 describes using Nexus to build a private server if you want to work in the real world. It is essential to use Maven in your work.

Chapters 10-16 cover some of the more advanced and discrete topics, including testing, continuous integration and Hudon, Web projects and automated deployment, automated version management, smart and flexible build to adapt to environment differences, site generation, and Maven’s Eelipse plugin m2elipe. Readers can read selectively according to their actual needs and interests.

Chapters 17-18 describe how to write Archeype and Maven plug-ins. The average Maven user doesn’t need this knowledge in the real world. If you need to write plug-ins to extend Maven, or if you need to write Archetype to maintain your project skeleton for your team, read these two chapters carefully.

Due to the details of the content is too much, so only part of the knowledge point screenshots out of the rough introduction, each small node there are more detailed content! If you want to get the Maven document, click the “Like” button to get it