- Gradle is definitely a functionally superior tool
- Gradle is dramatically faster to build - small multi-modules builds this is insignificant
- Many of Gradle's benefits are edge case or non-applicable
- Gradle uses DSL and has a very steep learning curve.
- DDL in maven means there is little question of what's expected
- DSL requires constant hunting on the internet and inside code
- Gradle uses Groovy which wil run java code but isn't Java - It's definitely it's own language
- Generic build tool for doing specific Java build/release
- Standard build/release steps for Java are not supported natively (maven release:prepare release:perform) and 3rd party plugins take wildly divergent approaches
- Some Gradle features are 'geeks-gone-wild' and serve no actual benefit. Eg. custom defined dependency scope
- No real expertise on Gradle.
- When you have a single release artifact (jar or docker image) multiple branches only add to the complication
- SNAPSHOTs allow for sharable artifacts without production releases
- Axiom: Sterling employees are your customers too! Don't release for company integration anything that isn't production ready.
- always release on master - chose which artifact deploys to which env.
- Default branch to be master
- Sorting imports is dumb
- We are all grown ups. You break it, you buy it
- No one is special
- Custom Error handlers a re producing the wrong messages and codes
- Custom end points
- Not using event driven programming
- No framework in place to keep microservices in sync
- No configuration discovery
- No service discovery