There are some other things. What you have described would work if jar has no dependencies (or is used as a library). When you build a deployable application yo

There are some other things. What you have described would work if jar has no dependencies (or is used as a library). When you build a deployable application you need stuff like: - building fat jar (jar with all dependencies, including transitive ones) or even whole docker image or just deploying the jar you created to the maven repository - unit tests - integration tests, with things like starting database - code coverage - dependency checks (version clashes of transitive dependencies, security issues) - code quality checks Additionally it is nice if you can do following through maven CLI: - update major/minor/patch version - deploy application to chosen environment - create javadocs for the project Above things are done through plugins, which release versions independently. Additionally plugins might have dependencies - for example maven-checkstyle-plugin depend on checkstyle checkstyle library - you might want to override checkstyle library version that is used by the plugin. Some plugins' default configuration might also not work nicely with each other - you need to update those. On top of that maven is using XML and on top of that maven creators chosen to make it even more verbose by ditching XML attributes. That way you end with really big pom.xml files (~3 times bigger than gradle file in this project).