Happy New Year, Spring community!
Hope you had great holidays and ready for new excitements in front of us.
After the rest and recharging during Christmas break I decided to pay honor to my favorite language back in days - Groovy.
And now it’s my pleasure to present you a brand new Groovy DSL for Spring Integration. You perhaps heard about our old attempt to make a Groovy DSL on top of Spring Integration XML support. But the solution was pretty cumbersome (especially for protocol-specific channel adapters) and support burden has grown tremendously. This my latest implementation is fully based on already mature Java DSL and its builder pattern support.
Having 10 years experience with Gradle I thought that it is going be easy enough for me to prepare quickly something what just extends an
IntegrationFlowDefinition and exposes a Groovy builder style for definition.
Turns out just using a language and engineering a DSL on top of it are different tasks, and I had to start learning respective Groovy aspects from a scratch.
A series of blog posts by Vladimír Oraný gave me a good source of information what and how should be used and done to make end-user experience with Groovy DSL as best as possible.
Including the current success of existing Kotlin DSL for Spring Integration, so far I ended up with a couple Groovy classes.
IntegrationGroovyDsl as a factory for
static integrationFlow() methods to be imported to the target project and delegation to the well-knows
GroovyIntegrationFlowDefinition as a wrapper around
Both classes heavily leverage a Groovy first class citizen -
groovy.lang.Closure, with a
@ClosureParams features to support IDE suggestions and auto-completion.
So, all you need is to have a
org.springframework.integration:spring-integration-groovy-dsl:0.0.1 dependency, add an
import static org.springframework.integration.dsl.IntegrationGroovyDsl.integrationFlow and start typing your
IntegrationFlow bean in a nice Groovy style.
And this is how it looks so far in my IntelliJ IDEA:
After learning those
You can find more samples in the project README and respective Spock tests.
If project matures, eventually it may go directly to
We also may override those
GroovyIntegrationFlowDefinition Groovy classes to Java (it’s just a DSL API anyway!), however I believe the
@CompileStatic Groovy feature should be enough to optimize compiled byte code in the end.
Give it a try and any feedback is welcome!