Maven Development Process Practice 4-(quick self-testing Web applications)

In the dark light, only one monitor is still on in Noo's office, with a pile of characters beating and a blurred back staring at the screen... That is it male Luo shuquan. The indicator lights next to the computer are blinking like fireflies, silent... There was a burst of cheers. This is a symbolic time,CodeThe basic development is complete.

The next step is the self-testing stage, a worrying and exciting stage. I'm glad that I can just relax after it is done. I am worried about Web applications.ProgramSelf-testing is very cumbersome, and it must be a loop between constantly modifying code and deploying web programs. Is there any good way? Sun seems to have mentioned a jetty plug-in for self-testing and debugging during development.

What is jetty?

It male Luo has read all the information, and his thoughts gradually become clearer:

Jetty is also a servlet container that supports war deployment, just like Tomcat we usually use. So why don't we use tomcat? jetty places emphasis on flexibility and scalability in architecture, and its core module is small. While Tomcat is more stable and powerful, it consumes a lot of resources.

In the self-testing stage, we need a server with basic functions, low resource consumption, and fast speed to improve the efficiency of self-testing. Therefore, Jetty is used as the self-testing server.

 

In the self-testing stage, there are two main types of self-testing development environment simulation. The first is self-testing of the complete code environment, generally after the compile lifecycle; the second is self-testing after packaging, generally after the package lifecycle.

 

First, configure the jetty plug-in POM:

 

1. MVN jetty: self-test of the run full code Environment

By default, the following parts of the full code environment are the scope of the self-testing environment:

• Resources in $ {basedir}/src/main/webapp
• Classes in $ {project. Build. outputdirectory}
• Web. XML in $ {basedir}/src/main/webapp/WEB-INF/

In this case, after the compile lifecycle, fewer startup and running resources are consumed, so the startup is fast.

But programmers often modify the code, so it is complicated to use MVN jetty: Run repeatedly. Therefore, the jetty plug-in provides the ability to automatically scan the changes in the above self-testing environment and restart jetty. It is very considerate. The scanning time can be defined by yourself in scanintervalseconds. Similarly, the scan range can also be customized.

 

 

2. MVN jetty: Run-war self-testing after packaging:

By default, search for $ {basedir}/target/$ {finalname}. War

In this case, it is equal to the full simulation of deployment, but the server consumes less resources. Of course, it will also scan for Project changes, mainly in the following locations:

Pom. XML, WEB-INF/lib, WEB-INF/classes and WEB-INF/Web. xml

 

 

I think this plug-in is quite practical. But he always felt that there was something missing, and the flying moth reminded him, debug.

You can use the following Configuration:

A). External tool Configuration

 

• Enter the MVN. Bat path in location.
• Enter $ {project_loc} in the working directory}
• Add the run parameter jetty: Run to arguments.

• Finally, add maven_opts to environment. The value is-xdebug-xnoagent-djava. compiler = none-xrunjdwp: Transport = dt_socket, address = 8000, Server = Y, suspend = n.

 

 

B) Open the project to be tested, select the defined jetty_debug Run Command, and then perform remote debugging on it.

 

With these user-friendly and convenient functions, the self-testing automation and Quick Start of the web environment saves time for self-testing and improves efficiency.

 

Jetty Reference documents:

1. jetty open-source project

2. Google chooses Jetty to discard Tomcat