Spring Framework and start.spring.io) • Involved in open source for 15 years (Apache Maven, Spring Framework) • snicoll on the Web (Twitter, Github) - [email protected] • Based in Liège, Belgium (come over, we have waffles)
Spring Framework and start.spring.io) • Involved in open source for 15 years (Apache Maven, Spring Framework) • snicoll on the Web (Twitter, Github) - [email protected] • Based in Liège, Belgium (come over, we have waffles)
practices for teams and the ecosystem at large • Provide sane defaults when you don’t or shouldn’t care • Make upgrade and maintenance easier • …. but shouldn’t get in your way • Built on top of an API you could use to implement something slightly or totally different • Can be customised without having you to redefine everything • Depending on the scope, not everything can be the target of a convention
for a very precise scenario: • Specific auto-configuration(s) • User configuration, if any • Environment tuning (properties customization) • System properties handling • Starts/Stop the context automatically with a ContextConsumer callback • AssertJ style assert • hasSingleBean, doesNotHaveBean, hasFailed • getBean, getBeans, etc