Gradle claims about build performance have nothing to do with reality - Maven builds are usually faster, especially for clean builds.
Maven configuration is much cleaner and simpler to understand and maintain, even for projects one is less familiar with. Gradle configuration is always different and every time one needs to understand it from scratch.
Maven is much better suited for larger projects, with deep nested structure. Gradle for long time required external plugin for centralized dependency management, for example. Maven projects naturally organized into nested modular structure, where each module contains necessary information to build it and its submodules. Often submodules can be built independently, without need to start build at the top level. Gradle uses centralized structure, where top level project knows all other subprojects, no matter how deeply they are nested.
This difference does not feel important until one needs to merge several independent projects into monorepo. Maven approach to configuration organization makes such a transition relatively simple. For Gradle this is quite complicated and sometimes tricky task.
Maven is much better backward compatible than Gradle. Old projects could be easily built with recent Maven version. This is not the case for Gradle. Upgrading Gradle build configuration for new version of Gradle is complicated and painful task given misleading error messages and useless documentation. In general this applies to virtually any issue with Gradle build - if you encounter something, be prepared for long googling, experimenting and guessing.
Still some issues are not fixed for years because nobody (including authors) can understand how they are happening. And only with Gradle I've encountered some bizarre behaviors even with well-known and proven tools. For example in one project I've observed how JUnit tries to pick up inner classes(!) of utility class(!) as a test. Excluding doesn't work (and why top class which has no 'Test' in name is even considered?), so inner class is marked as @Ignored. Which, in turn, triggers JUnit exception during build. Fortunately, this exception is ignored by Gradle so build passes.
Overall Gradle is good fit for Spring projects - both tools make development a constant fight with their "magic" which takes long hours and days. In turn they save you few seconds or even minutes by eliminating some boilerplate. Fantastic deal, isn't it?
Thanks for sharing your input Sergiy! It's interesting to hear about everyone's experience with the tools. I definitely heard many Gradle users experience "long googling" too -- I might have to add that to this article ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Gradle claims about build performance have nothing to do with reality - Maven builds are usually faster, especially for clean builds.
Maven configuration is much cleaner and simpler to understand and maintain, even for projects one is less familiar with. Gradle configuration is always different and every time one needs to understand it from scratch.
Maven is much better suited for larger projects, with deep nested structure. Gradle for long time required external plugin for centralized dependency management, for example. Maven projects naturally organized into nested modular structure, where each module contains necessary information to build it and its submodules. Often submodules can be built independently, without need to start build at the top level. Gradle uses centralized structure, where top level project knows all other subprojects, no matter how deeply they are nested.
This difference does not feel important until one needs to merge several independent projects into monorepo. Maven approach to configuration organization makes such a transition relatively simple. For Gradle this is quite complicated and sometimes tricky task.
Maven is much better backward compatible than Gradle. Old projects could be easily built with recent Maven version. This is not the case for Gradle. Upgrading Gradle build configuration for new version of Gradle is complicated and painful task given misleading error messages and useless documentation. In general this applies to virtually any issue with Gradle build - if you encounter something, be prepared for long googling, experimenting and guessing.
Still some issues are not fixed for years because nobody (including authors) can understand how they are happening. And only with Gradle I've encountered some bizarre behaviors even with well-known and proven tools. For example in one project I've observed how JUnit tries to pick up inner classes(!) of utility class(!) as a test. Excluding doesn't work (and why top class which has no 'Test' in name is even considered?), so inner class is marked as @Ignored. Which, in turn, triggers JUnit exception during build. Fortunately, this exception is ignored by Gradle so build passes.
Overall Gradle is good fit for Spring projects - both tools make development a constant fight with their "magic" which takes long hours and days. In turn they save you few seconds or even minutes by eliminating some boilerplate. Fantastic deal, isn't it?
Thanks for sharing your input Sergiy! It's interesting to hear about everyone's experience with the tools. I definitely heard many Gradle users experience "long googling" too -- I might have to add that to this article ;)