Folks,
following our team meeting in Antwerp I trimmed down the API+CTS that I had in the
incubator project to the functionality and concepts that we agreed on.
http://www.jboss.org/community/docs/DOC-12945
In Antwerp we decided that the threading model that is native to jBPM (i.e. borrowing the
client Thread) should be supported by the API, which actually makes a mapping to the jBPM3
code base possible.
How the API+CTS can be integrated in the Maven build is documented here
http://www.jboss.org/community/docs/DOC-12871
the Java Doc is here
http://jbpm.dyndns.org/jbpm-spec/jbpm-spec-api/apidocs/index.html
Doing this work for jBPM3 has multiple benefits.
#1
It will be much easier to decide when jBPM3 functional equivalence is reached
#2
Projects that require a stable API but also have a dependency on jBPM3 can start to
decouple from jBPM3 implementation detail and interface with the API. This is particularly
true for the GWT-Console and to some extend to the GPD.
#3
The migration to jBPM4 will be seamless for projects that use the API as an integration
point
#4
TomB who leads the API and provides an implementation for jBPM4 can reuse the jBPM3
integration and make good progress in jBPM4.
#5
Folks that know jBPM3 can start to provide qualified and meaningful feedback based on API
signatures and CTS test implementations
Over the next couple of weeks I still expect to see some movement in the API+CTS snapshot
artefacts until it becomes clear what will actually go into 3.3.1 and 4.0.0.Alpha1
respectively
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190004#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...