I\'m noticing a lot of projects (DropWizard, Grails, etc.) starting to embrace the notion of a \"fat\" JAR (using an embedded web server like Jetty or Tomcat) vs. the traditiona
Distributing an application with an embedded webserver allows for standalone setup and running it by just calling java -jar application.jar
.
However, there may be users who want to be in control of which web server is used or who want to deploy multiple applications into a single webserver (e.g. in order to prevent port clashes especially with ports 80 and 8080). In that case a "fat" jar might cause problems or at least some unneeded code and thus a larger memory footprint.
IMHO the best approach for those two cases would be to provide two artifacts: a "fat" jar for (easier) standalone setup and an application-only war/ear for those who want to deploy the application in their own container.
Here are some reasons:
In favor of JAR:
In favor of WAR or EAR:
Having said this, you can always provide 2 or 3 types of executables to cater to all needs. Any build tool makes this easy.
I am thinking about user perspective. You could wrap this one-self containing jar within a .exe or .dmg and just install it without the need to have additional instructions on how to deploy. Also, since you are doing the deploy for a particular server only, you could take advantage of that particular server