The venerable Ant build tool, hugely customisable with its custom tasks, finally gave way to the modern Maven ecosystem. That's natural evolution. New needs, new tools. History repeats, and Gradle builds upon all the goodness of Maven and includes many advanced (and more importantly useful) features like build-cache, parallel execution, Gradle daemons etc. Many major OSS vendors have switched after tasting the goods, Spring Boot included.
This enhancement request is to migrate SBA to a Gradle based build system.
Would be glad to submit a PR when you want to migrate.
Personally I'm not that much used to gradle and prefer maven. Also the comparison of maven is to ant as gradle is to maven imho doesn't work.
Migrating to gradle is a lot of effort as automated build and release process (including signing of the artifacts) would be affected.
Could you elaborate a bit on the advantages we would have using gradle? I'm currently not convinced if we should take this step.
IMHO, if we look from the perspective of "What's the cost of not doing it?" the answer is clearly a zero in the perceivable future. Again, from the perspective of "If it's not broken, why fix it?" the answer is clearly to stay with Maven. I'm with you on that, and moreso from the perspective of being the project owner and your own familiarity with Maven. Finally, we are talking about the build tool here and not SBA itself per se, so no real need to jump ship.
[x] Future contributors to SBA are expected to have a natural sway towards Gradle - just because they probably started their careers with Gradle. But honestly, I would think, the tooling itself (build tool, version control tool, code coverage tool etc.) should not matter most in the product. Bad analogy perhaps, but I don't use Ant or CVS/SVN for my new projects either.
[x] Now from an SBA developer's perspective, I like blazing fast builds, let's say sometimes a tenth of typical Maven builds - I would love that. Gradle build cache, parallel builds all help towards this. Scan reports are awesome. The HTML dependency graph is awesome. Generating jacoco aggregate reports is a breeze. Gradle plays really nice with Maven - no heartache with Maven at all. Every single artifact produced is 100% compatible with Maven built artifacts.
Any takers?
_(PS: Disclaimer - I'm not associated with the Gradle project or Gradle Inc. in any way whatsoever)_
Most helpful comment
IMHO, if we look from the perspective of "What's the cost of not doing it?" the answer is clearly a zero in the perceivable future. Again, from the perspective of "If it's not broken, why fix it?" the answer is clearly to stay with Maven. I'm with you on that, and moreso from the perspective of being the project owner and your own familiarity with Maven. Finally, we are talking about the build tool here and not SBA itself per se, so no real need to jump ship.
tl;dr
[x] Future contributors to SBA are expected to have a natural sway towards Gradle - just because they probably started their careers with Gradle. But honestly, I would think, the tooling itself (build tool, version control tool, code coverage tool etc.) should not matter most in the product. Bad analogy perhaps, but I don't use Ant or CVS/SVN for my new projects either.
[x] Now from an SBA developer's perspective, I like blazing fast builds, let's say sometimes a tenth of typical Maven builds - I would love that. Gradle build cache, parallel builds all help towards this. Scan reports are awesome. The HTML dependency graph is awesome. Generating jacoco aggregate reports is a breeze. Gradle plays really nice with Maven - no heartache with Maven at all. Every single artifact produced is 100% compatible with Maven built artifacts.
Challenges with the migration
The rewards of migration
Any takers?
_(PS: Disclaimer - I'm not associated with the Gradle project or Gradle Inc. in any way whatsoever)_