When it comes to arguing the virtues of Jenkins vs. Maven, there really isn't much to debate.
If someone asked me to choose between the two, I'd put a ring on Maven's finger and never regret terminating my relationship with Jenkins. I really can't think of a build tool that has done more to make software development easier for me than Maven.
Maven vs. Jenkins: Java ecosystem contributions
Why do I consider Maven king in the Maven vs. Jenkins debate? Largely because of all of the incredible things I can do with the Apache build tool.
With Maven I can run a single archetype command and create the skeleton of a fully compliant Jakarta EE, Spring Boot, Java EE MicroProfile or Android application. Writing a Maven plug-in is easy, as doing so only requires a basic knowledge of Java programming. Because of this low barrier for entry, a rich set of Maven add-ons exist, ranging from code quality quantifiers like PMD to McCabe cyclomatic complexity reporting tools like Jacoco. Maven is Java-based. Maven's installation couldn't be simpler. And Maven doesn't need to be hosted in a servlet engine. These are just a few of the reasons why Maven wins in any Maven vs. Jenkins comparison.
And as impressive as these aforementioned virtues are, they don't even touch upon Maven's greatest contribution to the Java development community, which is the fact that Maven solved the contemptuous problem of resolving dependent JAR files at runtime.
Prior to the advent of Maven, Java developers wasted far too many clock cycles wondering why the log4j dependency was unsatisfied on the production server, or why pre-prod was encountering a SunCertPathBuilderException every time a remote session was invoked. Maven's ability to consistently build Java applications across disparate development stages, all while maintaining linked library consistency, can't be overstated. The capacity to resolve linked libraries is a facet that is now taken for granted, but it shouldn't be. It's an amazing technical feat.
In fairness, Jenkins can do some cool stuff, too. Jenkins builds can be highly parameterized, and Jenkins can easily modularize builds into multiple steps, such as compile, test and package. Maven can even deploy production-ready artifacts to remote servers or software repositories.
It's worth nothing that when Jenkins deploys artifacts to remote repositories, those repositories are typically Maven repositories, such as JFrog's Artifactory or Sonatype's Nexus. Furthermore, what underlying technology does Jenkins use to perform the package and deploy steps? Jenkins tends to package and deploy using the same underlying technology that performs compilation and runs tests: the Jenkins Maven plug-in. Even when Jenkins appears to be doing something useful, behind the scenes, it's actually the Maven plug-in that does all of the heavy
Of course, the Maven build tool is by no means a software development panacea. Maven has plenty of shortcomings.
Maven vs. Jenkins: Programming
Lacking a friendly programming framework, modularizing Maven builds and linking modular build steps together can be a pain. It's been said that most of the stuff you want to do with Maven is incredibly easy, but without a programming model built around it, doing something challenging, like turning Maven into an integration server, is a completely futile quest. And that's precisely where an integration server like Jenkins earns points in the Jenkins vs. Maven debate.
Sir Isaac Newton reportedly once said, "If I have seen further than others, it is only by standing on the shoulders of giants." If Jenkins is the most downloaded and most actively maintained CI server on the market today, it's because it too stood on the shoulders of giants; giants with names like Maven, Gradle, SonarQube and Git.
Reframing the Jenkins vs. Maven debate
Jenkins doesn't need to compete with Maven in terms of compiling
Truth be told, the Jenkins vs. Maven argument is a
How to become a Jenkins expert learning path
Part 5 -- Framing the Maven vs. Jenkins debate (this one)