Let's think back, how did we build the project before maven.
With the familiar tool eclipse, to create a project, we will create a new project or dynamic web project, and then copy or write the configuration file. We may put the configuration file in the src root directory, or we may build a new one in the src directory config or other directories are used to store configuration files; for web projects, some people may also store configuration files in the WEB-INF directory; next, you need to copy lib, for ordinary projects, you may build one in the project root directory The lib directory is used to store the jar package, and then add the jar package to the classpath. For web projects, copy the jar package directly to the WEB-INF/lib directory; for example, we need to add spring's jar package, we may go to spring's Go to the official website to find the corresponding jar packages, then download them one by one and add them to the project; if the spring project also depends on other jar packages, such as commons-logging, go to the corresponding official website to download, or download a complete package with dependencies , which contains spring and its dependencies, and then add these jar packages to the project together; of course, for an experienced driver, he may have downloaded the spring jar package in the local directory, just from the disk Make another copy and add it to the project. Next, start writing code, build the corresponding package, and start developing. During the development process, continuous compilation is required, which is generally with the help of tools, and the automatic compilation function is generally turned on. After the development is completed, or some modules are developed, it is necessary to test and write unit tests. We may create a new test class directly under the corresponding package before. Better, we will create a test source directory under src to store test-related code. The following figure shows the project structure created in the traditional way:
After testing, the next step is packaging. Generally, tools such as eclipse's export are used. After exporting, the jar package or war package is uploaded to the remote server. This can usually be uploaded with the help of FTP tools such as winscp, and then to the server. Start the service.
The above is the construction process of the project, including project creation, compilation, testing, packaging, deployment, etc. We do these things every day.
Let's summarize the shortcomings of the traditional construction method:
1. The project structure is chaotic. Some people like to put the configuration files in the src root directory, some people in the WEB-INF directory, and some people in their own directory. When we get a new project, we have to go to Guess where the configuration file is stored, our goal is that any project is a familiar style;
2. It is troublesome to add dependencies. We have to go to different official websites to download jar packages. Sometimes jar packages are not easy to find, and we have to use search engines. In addition, after jar packages are downloaded, we will store them on the local disk, and manage them by ourselves when there are few jar packages. It's easier to handle. Once there are too many jar packages, different jar packages, and different versions of the same jar package, we may not be able to manage them, and the disk will be very messy. This is simply unbearable; in addition, we put the jar package In the copied project, each project will independently store a jar package on the disk. Although a single jar package is not large, but there are many projects, it will also cause a waste of disk space;
3. Test code In the past, our test code was mixed with the official code. For standardization, a test directory may be established under src to store the test code. However, when packaging, these test codes are packaged together with the official code. , released to production, and test code should not be released to production;
4. Too much manual labor in compiling, packaging, and deploying. In traditional project construction, the compilation is good. We will use the automatic compilation function of the tool, but testing, packaging, and deployment all require manual operations, which are time-consuming and labor-intensive.
The maven we will introduce next is used to solve the above defects.