Maven tomcat plugin: tomcat7:run or tomcat7:run-war?

Question

I am using tomcat7-maven-plugin in my Java web application. Now I can run my web server using command mvn clean tomcat7:run. Recently I notice that there is another command called tomcat7:run-war from https://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/plugin-info.html, which says:

tomcat7:run:
Runs the current project as a dynamic web application using an embedded Tomcat server.

tomcat7:run-war:
Runs the current project as a packaged web application using an embedded Tomcat server.

I know the command tomcat7:run-war will package my application to a jar or war file and then run it inside an embedded server. My question is that under what circumstances should we use this command, isn't tomcat7:run enough? Or maybe running a packaged application will have higher performance? I am not sure. Thanks in advance.

Answer 1

Short answer

The running application and server performance are equal. However, you usually want to use run-war because it gives you the extra benefit of delivering a war file. You want to use run if you absolutely need to get your application to run locally as fast as possible (hardly ever the case).

---

Here comes the details

Let's start with what a war file is and what it is created for:

WAR. Is the extension of a file that packages a web application directory hierarchy in ZIP format and is short for Web Archive. Java web applications are usually packaged as WAR files for deployment. [Baeldung]

Why are java web apps packaged as WAR?

Because WAR is not only a zip file but (correctly built) enforces the Java web application specifications. You can deploy and run a war file on any container. Checkout Wikipedia for more advantages.

Different goals, different outcome

The goals tomcat:run and tomcat:run-war both start your application on an embedded tomcat server. tomcat:run-war includes an extra package goal to package your application in a WAR-file. This WAR-file will then be unpacked by the embedded tomcat server to be able to run the application. So the application and server are the same, but the outcome is different for run-war, because you get the extra WAR-file.

But how is that WAR-file useful?

First of all, there is no disadvantage to it, except for a few seconds more build time. Even hot swapping tools and features work with a WAR-file in between. The main reasons for creating the WAR-file as a part of that goal are:

• Testing
• Multiple deployments
• CI-pipeline
• Archiving

Testing. Building a WAR-file means your build pipeline undergoes all steps of a WAR-build. As you will later deploy that WAR-file (reminder: its the standard for containers) you can test that the 'build', 'unpackage' and 'deploy' steps work correctly. Futhermore, you can inspect the structure of the file if it does not.

Multiple deployments. You might build and run the application locally, but you can still deploy that WAR-file to more than one container that you have running. There are industry scenarios where you need to make sure that your WAR-file runs on different containers and you can use the file to deploy it anywhere.

CI-pipeline. You might not only want to the application locally, but integrate the result into your continuous integration. Maybe you even deploy a local build to a test server automatically, but more likely is that you have an automated process on a CI-server that builds the WAR, runs it on some test or staging system and forwards the WAR afterwards if that works correctly.

Archiving. You might want to keep all past build WAR-files. May it be for one of the other reasons mentioned or just as a backup for fast historic access. It can also be interesting to see how the disk space and memory usage evolve with a growing application. Archiving the WAR-files is a way to investigate that. They might also be deployed to a WAR archive-server.

---

Conclusion

Both goals have their usage, but it is usually preferable to use the run-war goal because of the benefits you get by additionally building the WAR-file.

Disclaimer

As this topic is a bit out of date, I might add the following: I am just giving a historic review. The use cases and needs might differ today for each individual use case. Some processes, maven-goals and plugins are outdated or better practices have emerged. I am just explaining possible intentions behind that goal at the time it was developed.