Whether to WAR or JAR with WildFly Swarm?

With most things in life we have choices, sometimes a few and sometimes many. When it comes to WildFly Swarm projects with Maven the two choices are war or jar packaging.

Each has different benefits and tradeoffs which we will discuss during this article. By the end I hope it’s clearer as to the best situations to utilize either packaging type.


There are two ways we end up with jar packaging with Maven:

  1. Don’t specify <packaging> in pom.xml, as jar is the default.

  2. Explicitly set jar packaging:


What are the benefits of this approach:

  • Simplified project structure as only deals with classes and resources

  • When using a custom main(), provides easier construction of a Shrinkwrap WAR deployment from classpath resources

But what are the downsides:

  • Requires a custom main() if you want to create a Shrinkwrap WAR deployment

  • Can’t be deployed to regular application servers


The only way to indicate war packaging is with:



  • Deployable to any container/server that accepts .war files

  • Don’t need a custom main() to construct the Shrinkwrap WAR deployment

  • More common practice for development by those familiar with Enterprise Java, such as Java EE and Spring

  • Better tooling integration in an IDE


  • Slightly more complicated project layout. I say that loosely though, especially as most Enterprise Java developers are more than familiar with war project structure.

What’s Best?

As with all things, there isn’t one size fits all!

In the below table I will layout in what situations one or the other should be utilized:

Packaging Web Deployment Non Web Deployment Custom main()


Could be done with a custom main(), but not recommended

YES. Recommended for messaging and scheduled type microservices that don’t require exposed endpoints.

If needed for customizing fractions. Please raise issues for what’s missing for it to be configured via yml.


YES. Recommended

Would require custom main() to convert WAR structure into JAR deployment.

If needed for customizing fractions. Please raise issues for what’s missing for it to be configured via yml. Not recommended for creating a web deployment, as Maven has already done that for us.


From this brief foray into the world of Maven packaging and WildFly Swarm, we can see that for most situations sticking with the typical war packaging is our best option. It provides the closest match to regular Enterprise Java development and will result in a more seamless transition developing with WildFly Swarm.

Don’t be afraid to let us know we’ve messed up and you’re not able to configure a fraction with project-stages.yml and you needed to create a custom main(). We are keen on removing all those types of problems such that a custom main() is only required in the most advanced use cases, and preferably not even then!