The last SCXML release 0.9 has been quite some time ago (2008) and since then the W3C SCXML specification has progressed and changed quite a lot, and almost ready to move to Candidate Recommendation status.
The goal for Commons SCXML 2.0 is to get alignment (back) and be compliant with the W3C SCXML specification, but for this a lot of major changes are needed, both to the public API and, even more so, to the internal model and processing logic.
To be able to make such major changes in an effective way, we already cleaned out a lot of the old but no longer relevant, working or otherwise incompatible features from the previous SCXML (0.9) version, see Milestone 0 below.
The work needed towards Commons SCXML 2.0 has been divided in a set of high-level targets and corresponding milestones:
The first and already completed target was to cleanup and clean out no longer relevant or even no longer working features, or features which would make it very hard or complicated to keep working and supported for the major changes ahead.
The support for the following features and integrations has been dropped: Shale/JSF, Rhino/E4X, Servlet/JSP.
Note: some of the dropped features might be restored or re-implemented again once we reached a reasonable level of stability for the new APIs and internal logic, but that also will depend on the level of interest and support from the community.
Technically, this milestone 0 still is largely compatible with the 0.9 release, just without those above mentioned features, and also now requires Java 6+. In addition this milestone also contains several fixes and enhancements (like Groovy language support).
The target for milestone 1 is a redesign and better separation of concerns of the main SCXML processing components: SCXMLSemantics, SCXMLExecutor and SCInstance.
The high-level plan is to:
The main target for milestone 2 is to get better alignment with the SCXML datamodel specification.
The Commons SCXML datamodel and context features are very flexible and can be defined and redefined in a hierarchical way (per state element). However this also makes it much more complex to manage, especially for XPath (XML) datamodel definitions.
The SCXML specification however is very explicit in its requirements that, while datamodel elements may be defined in multiple locations within an SCXML document, together they must be accessible (and thus managed) as a single datamodel definition.
The current Commons SCXML datamodel (and the backing Context handling) is to some extend actually more flexible and generic than what is possible AND allowed by the specification.
To be able to be compliant with the specification, the default datamodel management in
Commons SCXML will have to be more restricted and simplified.
It is the intend to also retain the current flexible Commons SCXML datamodel and context features, but provide this as custom extension, no longer as default.
The additional target is to be able to now run a substantial number of the SCXML IPR tests. Currently almost all still fail because of (simple) expression language issues, so fixing and improving the language support is an important goal as well.
The target for milestone 3 is to complete the remaining SCXML Processor and SCXML I/O Processor required features for external communications (send and invoke elements).
If and when all of the above milestone targets are met Commons SCXML should be very close to being in compliance with the SCXML specification, and/or in any case at a good enough level for all practical purposes, to be released as Commons SCXML 2.0.
As part of validation the implementation, the SCXML 1.0 Implementation Report Plan will be used to test against.
Even though the IRP is not intended to be used for conformance testing of implementations, it is very much used as a functional benchmark, also by other SCXML implementations.
There are still plenty of optional features in the SCXML specification which might be very useful to support, like ECMAScript+JSON datamodel or HTTP Event I/O Processor support.
Also, adding extensions outside the specification, or bringing back some of the features dropped for milestone 0, like integration with other frameworks or expression languages (Servlet, EL, etc.), will be considered again.
For the above milestones specific VCS milestone tags will be set, like commons-scxml2-2.0-M0.
These milestones tags however do not represent a formal release and are only intended to be used for testing purposes by Commons SCXML developers.
Developers willing to test and validate these milestones can do so by checking out these tags and building and deploying a milestone version into their local Maven repository.
Such locally installed milestone builds then can be used in your Maven project using a dependency configuration like below (using milestone 0 as example):
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-scxml2</artifactId> <version>2.0-M0</version> </dependency>