Milestone 0: Cleanup (completed: 2014-03-11)

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).

Milestone 1: Redesign semantics and processing components (completed: 2014-04-03)

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:

• Redefine SCXMLSemantics to align with the SCXML Algorithm for SCXML Interpretation

  The current SCXMLSemantics interface and its implementation is so much different from the algorithm in the specification that 'molding' it into what the algorithm now expects is too cumbersome.

  Also, developers wishing to extend or customize the SCXMLSemantics will have a hard time to match that against the algorithm as well.

  The intend therefore is to start with a new SCXMLSemantics interface from scratch which (largely) follows the algorithm in the specification.

• Better separation of concern between SCXMLExecutor and SCInstance.

  The purpose of SCInstance is to be used as backing store for internal SCXML state. However over time some processing and transient state based features have ended up in SCInstance which are more appropriated to be managed by the SCXMLExecutor instead.

  Conversely, SCXMLExecutor maintains the current Status for the SCXML state as well as the internal events list going with it. Having the Status, without the processing related events list, to be managed by SCInstance instead would be better fitting.

  And finally, SCXMLExecutor currently doesn't yet provide a good abstraction or implementation of the SCXML Event I/O Processor functionally. The internal and external event I/O management is a critical requirement and many features of the specification rely on it fulfilling this contract.
  The goal for this milestone is to provide a least a basic level of support for the SCXML Event I/O Processor and Event queue handling features.
  

  Overall, the intend is to let SCXMLExecutor be responsible as SCXML Processor and SCXML I/O Processor and to maintain all transient processing state including the system variables, while delegating to SCXMLSemantics for dealing with the processing algorithm.

This milestone has now been completed and the most prominent changes and new features can be reviewed through JIRA issues SCXML-196, SCXML-197 as well as SCXML-200.

Milestone 2: Datamodel and expression language aligment

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.
That will actually make things much easier to implement. For an XPath (XML) datamodel then only a single (aggregated) XML datamodel document can be used and the custom Commons SCXML Data() function no longer will be needed to access the data elements.

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.

Milestone 3: External communications support

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).

Commons SCXML 2.0 release

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.

Commons SCXML 2.0+: Optional SCXML features

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.

Milestone tags

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>