VMware offers training and certification to turbo-charge your progress.Learn more
We’re pleased to announce a release of Spring Statemachine 1.0.0. I'd like to start by saying thank you for all who contributed in any way to make this happen. Artifacts are available either from Maven Central or from Spring Repository.
What we actually got into this first release:
Lets take a quick recap how this project was born and how it evolved from first github import into a release. This also gives a little background how a new spring project is born or might be born. Project was kicked off at early parts of this year from a base work done for Spring Hadoop.
For SpringOne 2014 which were held at Dallas we were pushing a new container grouping feature into a Spring YARN which added a more high level functionality atop of YARN containers. These days YARN runtime for Spring XD and new Spring Cloud Dataflow YARN deployer are based on that. Communication with a Hadoop YARN resource manager is asynchronous by its nature so I ended up having a lot of trouble by trying to implement this specific part of a codebase without using a proper state machine concepts. Believe me when I say that I tried, tried really hard not to use a proper states and after a week or so I had to face a reality and face a fact that I tried to out-code my own code. I kinda ended up having something which marginally worked but if I touched any parts of that code hell broke loose. I rm'd everything and said to myself, "goddammit Janne, I need a state machine".
After I completed a base implementation of a state machine, literally all my problems vanished, simply because a state machine was now controlling all the logic which had to happen in a specific order while all communication towards a YARN resource manager still happened asynchronously. And yes, now that we've stepped into a release phase, it gives us an option to replace Spring YARN internal state machine with this release.
Idea was born that it would probably be a really good idea to fork this specific state machine code into its own project, enhance it a little and fire up a new Spring Project and see if it gets any traction. If being honest I was a little surprised how much interest it got with this tech which is more than 50 years old. Good and solid concepts just don't die nor they need to die!
Few words about a challenges I faced during this journey getting from an idea into a release:
Aphyr'sJepsen framework for this which, if mildly speaking, put things is pieces, but eventually allowed me to find all sort of bugs when you step out from a single JVM and start to work with a distributed JVM's. This was a painful but interesting journey.
Many people have asked if we have a roadmap? Short answer is yes and no. Yes because we definitely have a lot of stuff we want to implement and no because project has been driven by requests from a community. I started to follow UML state machine spec for base features but eventually about 50% of extra features were requested by users. UML spec if very vague for some of its specification features and leaves a lot of details into the implentation itself. If you want something, speak up and go to GitHub Issues. Want to contribute, PR something(even a simple fix for a typo is very much appreciated!).
What we know so far:
Spring Sessionto secure state machine actions. For execution we're looking to replace or give an shot for Reactor in favor of normal Framework task scheduling/execution.
Try it, feel it, sniff it, and let us know what you think!