PVM 1.0 countdown

[mvaldes]

Tom,

Hereafter a list of topics I see to be addressed on the road to release the PVM 1.0:

- Maven migration: the move from ivy to maven seems close to be finished, however there are still some refactorings to be performed: some duplicated classes, some unit tests should be fixed, some libraries are missing, i.e JUEL engine.

- Activity instance concept has been removed from the PVM sources, seems like finally we will come back to the previous implementation, probably some refactorings are needed on the source code and tests. We noticed that you started some work related to chlid executions when entering in a node, is this development related ?

- Timers refactoring: there is still some refactorings to be performed on the way that timers are supported. We are currently finishing this development, specially the support for dynamic setting of timers.

- Unit tests refactoring: before the maven move, some unit tests were not included in the unit test suite and so were not up to date. We are currently fixing those tests.

- DB unit tests: this is still a big tasks to be performed. Most of the unit tests concerns the in-memory execution so the persistent mode should get the focus now. Two possible strategies could be envisoned: to reach a good coverage of unit tests related to atomic persistence features vs focus on some persistence uses cases.

- Validation and stress testing: our validation team is setting up the test environment for the PVM starting from the Bonita and Orchestra configurations. They are currently working on two different uses cases in which both transition based and nested node based executions will be stressed. We should agree on other use cases.

- PVM refactoring: you started some refactoring at the same time that the move to maven happened. Probably there are some source code which is not in synch with the current trunk version.

- DB schema stabilization: this tasks is related to the unit test persistence one. Schema stabilization is probably one of the most important remaining tasks to be done.

- JIRA issues priorities. A number of tasks are available in Jira but probably not all of them are mandatory for th 1.0 release. There are some of them classified under the beta1 component so we should focus on those ones first + agree on the ones that we want to be included in 1.0

regards,
Miguel Valdes

[heiko.braun]

fixed, some libraries are missing, i.e JUEL engine.

I did put any library that I could see being covered by a unit test. To put it the other way around: if the test suite passes with a library it doesn't seem to be necessary.

So either the test exists, but is currently excluded or the test for functionality that requires a particular library is missing.

[heiko.braun]

A general question on the roadmap:

First of all I don't see a PVM 1.0.GA on the roadmap at all. The next one is beta1. In general anything you mention should be backed by Jira issues covered by unit tests. Otherwise they cannot be assigned and will easily slip through the release.

But a more general concern I have is, how can the PVM become 1.0 when there is no single line of jPDL code? If the jPDL 4 will be build on the PVM then it will go lock step with the PVM release, meaning that the PVM get's 1.0 GA when jPDL is. How can be sure that the PVM doesn't require further changes otherwise?

[porcherg]

fixed, some libraries are missing, i.e JUEL engine.

So either the test exists, but is currently excluded or the test for functionality that requires a particular library is missing.

org.jbpm.pvm.expr.ExpressionTest uses juel engine, which is missing.
It's currently excluded in maven tests, but this test was successful with the 'ant' pvm.

regards,
Guillaume

[mvaldes]

A general question on the roadmap:
First of all I don't see a PVM 1.0.GA on the roadmap at all.

This is the problem, there is currently no clear definition of the PVM 1.0 release so would be great to start thinking about :-)

The next one is beta1. In general anything you mention should be backed by Jira issues covered by unit tests. Otherwise they cannot be assigned and will easily slip through the release.

I agree and this is why I started this thread, I would like to planify with Tom this release as well as minor releases inbetween.

We will start with this process next week as soon as Tom is back.

But a more general concern I have is, how can the PVM become 1.0 when there is no single line of jPDL code? If the jPDL 4 will be build on the PVM then it will go lock step with the PVM release, meaning that the PVM get's 1.0 GA when jPDL is. How can be sure that the PVM doesn't require further changes otherwise?

The current PVM source code has been leveraged for the last couple of months by both XPDL and BPEL extensions hosted in OW2 consortium (Bonita and Orchestra projects). We want to release a final version of those extensions begining of september (RC2 versions are avilable since JavaOne) so I would like to do it over a final and stable version of the PVM...

JPDL extension should be pretty close to XPDL one in terms of PVM requirements so I don't see major changes/refactoring to come.

We have already discussed a lot of times about this topic with Tom and he always tell me that there is a risk for changes in the PVM if some issues come out when developing the JPDL extension. I understand this point but we need to start the stabilization process ASAP to allow both teams (Jboss and Bull) to well define our projects roadmap.

PVM 1.0 doesn't means to include all the native advanced features in this release (process modifications, instances migrations...) but a good set of them that already allows us to build our extensions on top JDPL, XPDL and BPEL... other features can be included in further releases.

I think in terms of features we have already a good coverage that justify the release of a 1.0 release.

I will be on vacations next week but my team will be 100% focus and available for the roadmap definition and related work. As already discussed with Tom best option would be a face to face meeting (working session) in Turnhout.

regards,
Miguel Valdes

[heiko.braun]

I see. Thanks for the clarification.