To WAR or JAR
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
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:
jaris the default.
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
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.
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.
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
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
We are keen on removing all those types of problems such that a custom
is only required in the most advanced use cases, and preferably not even then!