A Preliminary Exploration of Maven

    I used to chat with a friend who was doing the Internet and asked me if I used maven. I said no, but they couldn't do without maven. Then I thought about it, why don't we use it here? A large number of them are maintaining a system. Faced with performance requirements, continuous optimization, optimization and re-optimization are the only goals.
    On my side, I have to manage multiple projects, communicate with multiple users, and lead some technical personnel to work, so I use a familiar, stable, and simple technical framework (and it is quite an old technology), and many times from The basic project is copied and new projects can be started immediately, so that our energy is concentrated on the business and does not require continuous technical updates.
    It can be said that we are in different ecosystems, adapt to different business environments, and develop towards different centers of gravity.


     Of course, I'm still very interested in new technologies, so I spent a day researching maven. The most important thing is to build a web project in myeclipse, run the compile configuration, and deploy it to tomcat.
   
     For new technology, what I want to summarize most is why it appeared, what was the purpose of the original inventor to do such a thing, and what problem was it trying to solve? I basically think it is: maven is just a glue, through a pom.xml configuration file, all the related packages to be used, related compilation, packaging, deployment are integrated together, it is a tool for commander-in-chief .

     The specific code is not posted, there are a lot of them on the Internet, and I pay attention to understanding here. When I was working on a maven web project, there were mainly a few problems with the process and experience.
1. It conforms to the maven project structure, especially the webapp is placed under src/main. Other main, test source code is nothing special.
2. Of course, including the introduction of jdk and jave EE, set the web-root location
3. The key point is the pom.xml file. In addition to defining my own project, the focus I use includes two parts: one part is dependencies (or materials). This is easy to understand. You must introduce other jar packages. There are A concept of dependency scope. The other part is plug-ins (or tools), such as plug-ins for war packages and tools for deploying to tomcat. Deploying to tomcat is a hot deployment. Start tomcat first, provide the plugin with the management address, and provide the user and password. In this way, the front is marked as a war package, and the latter is thrown into the webapps of tomcat. very convenient.
4. The outermost layer of the plug-in in pom is the build tag, indicating that it is a tool used in the build process.
5. Maven has so many dependencies and so many plug-ins are ready-made. In fact, there is a remote warehouse, which can be accessed by name and coordinates. When running, it will be taken remotely and placed in the local warehouse for use. The local repository has a settings.xml configuration. I started to configure the user password of tomcat here, the deployment failed, always 404, and then it was successfully placed in the pom.


    Basically get a project, there is a concept, it is very effective in managing large applications. When I got here, I was very concerned about plugins, so I found a post on how to write plugins myself and read it.

    1. Write a Mojo. Mojo = Maven Old Java Object, which needs to inherit AbstractMojo and implement its execute method.
    2. The file information in the project path can be obtained through annotations, and then the execute in the tool can be used to process these files. Either process the source file, or process the result goal. For example:
     /**
     * @parameter expression="${project.basedir}"
     * @required
     * @readonly
     */ 
    private File basedir;


   Through the development of a plugin, we can better understand the working principle of maven.