GSoC proposal: Process instance migration in JBPM

[tom.baeyens]

For this proposal, I think the following timeline is achievable:

Milestone 1 (approx 7 days): Get overview of the jBPM codebase and learn the build system.

Milestone 2 (approx 12 days): Work out the simplest possible example and discuss the proposed solution. Starting points: add a property to the deployment (probably as an attribute in the process definition). Add process instance migration code to the JpdlDeployer.

Milestone 3 (approx 7 days): Add a translation map in case activity names have changed. Define how this mapping information will be part of a deployment.

Milestone 4 (approx 15 days): Analyse exact constraints for migrating process instances over to a changed process definition. What kind of changes can be handled. And what kind of changes cannot be handled. Add those constraints to the process instance migration.

Milestone 5 (approx 15 days): Develop a testing strategy for process instance migrations.

[jbarrez]

Imo, 7 days for learning jBPM codebase from scratch is a bit short. Unless someone will tutor the guy/girl ... but in my experience this should be at least 12 days (learning + buidling small examples)

[heiko.braun]

'cmon, it's just another state machine.

[jbarrez]

True, but it takes a time untile people tend to see that.

I've given jBPM courses in the past, and for some reason or the other it takes a time to 'get into the framework'. If the student needs to tackle the problem of process migration, it first needs to understand why it is a problem... unless the student has a BPM background.

For the other sections of the problem, I think too much time is forseen. For example building the simple approach with a property based solution doens't need 12 days ... if you know the codebase (which takes me to my previous remark) ....