- Tom Baeyens
- Joram Barrez
- David Syer
- Micha Kiener
- Agim Emruli
- Christian Stettler
- Stefan Niederhausen
- Bernd Ruecker
- Jacob Fruend
- Ross Mason
- Christian Mulder
Dinner day 0
We'll go for dinner and this is a perfect occasion for other people to join informally to meet up.
I assume we'll meet up somewhere around 19:30 in some restaurant in Stuttgart center. We'll add more concrete details later.
Please put your name here or send me (t o m a t alfresco d-o-t com) a mail if you want to join so that we can book a restaurant.
- Tom Baeyens
- Joram Barrez
- David Syer
Agenda day 1
9:00 - 10:00
10:00 - 10:30
Round of introductions. Every company gets 12 minutes :-)
10:30 - 11:30
Where Activiti came from. What made jBPM successfull?
11:30 - 12:00
Anticipated timeline (incl compatibility guarantees)
13:30 - 18:00
Roadmap discussions. We'll split up all the features in
18:00 - 04:30
Dinner day 1
We'll probably meet up around 18:30 somewhere in the center of Stuttgart. Later will list the exact time and date. List your name if you want to join.
Agenda day 2
9:00 - 10:30
Infrastructure, Decision process & Sprint layout
10:30 - 12:00
Task assignments / commitments. Here we go over the prioritized roadmap that we target for November and see who are volunteers for which tasks.
13:30 - 15:00
16:00 - 17:00
Roundup + group hug
Activiti phases towards 5.0
- Now - end July
- Finish PVM feature implementations
- Most BPMN control flow activities
- July - August:
- PVM API stabilisation
- Finish BPMN feature implementations
- September - October
Compatibility between releases:
- What guarantees
- Automatic upgrades
Goals of he meeting
- Define the roadmap as concrete as possible
- A lot of initiatives have impact on roadmap
- distill most important decisions
- analyse impact on roadmap
- discuss and decide on those important decisions
- come to a concrete achievable roadmap
that way we all know what we can expect this year
- Get to know each other to improve the collaboration
- Clarify which parties take on which task assignments and responsibilities and commitments. Work is only pulled by volunteers. No workload is being pushed to community people.
Other potential topics
Biggest question around BPMN is the suitability for developers. jPDL was much more readable. Will BPMN shortcut suffice? Will just have to take the pain of a verbose language? Or do we need to go for usability, compactness and readability without compromises.
How do we make it easy for users to work with all these namespaces (if we decide to put custom conveniences in namespaces)
Is there a clear scope we can target? Simple or descriptive conformance? Maybe Bernd could prepare this topic as he's closest to the spec. But most important is not the knowledge of the actual conformance, but arguments that give us guidance on what kind of conformance we target and how strict we'll be. The alternative is that we define our own subset of what we think is useful.
Database upgrades. Automatic QA for upgrade.
Extracting PVM into separate library?
Define which aspects need to be pluggable/configurable and which not.
Currently our strategy is to combine the PVM with other components like task management and command interceptors into the core activi jar. So the biggest question is if we will be extracting the PVM into a separate project jar, and productize it. Roughly, the downside of extracting it is that we'll have to define a very clear boundary between what is in the PVM and what is not. This will also lead to more decoupling and hence more indirections being placed. That might impact the readability and simplicity of the whole engine.
Further, it only makes sense to extract the PVM if we do the effort of productizing it. Meaning, have a specific documentation set for it and also build out a test suite for the PVM itself.
Currently we have the PVM design as the basis, but we avoid all this because of practical reasons: 1) We can go faster in terms of features if we combine the PVM with the other components. 2) We don't have to do the effort of productizing (QA + docs) of the PVM component itself.
One aspect of this is timer sessions and message session: Currently, timers and async continuations are part of the PVM infrastructure. This implies that the CommandContext, Interceptors, Service API also should be included in the PVM. Is that desirable?
Another aspect is testing. The test helper methods often want to make use of implementation classes. Even if the test method API doesn't expose the impl classes, those test helper classes always will have a dependency on the implementation lib.
iBatis, JPA and others?
Is the current architecture OK for 5.0?
The biggest question here is: How will we align the roadmap of researching the cloud solution with the roadmap towards 5.0GA in november?
An important aspect of cloud is the query API. We currently plan to build out the query API similar to jBPM 4. For example
But that might be hard to implement on cloud persistence. Maybe there are solutions. MapReduce?
For persistence, we can serialize the process instances to JSON. Diff between DB is then still granularity: Cloud stores whole process instances, DB stores executions individually. Implementations of PersistenceSession impl should be able to cope with this diff by using the object's relations in the cloud.
- Process instance migration
- History / reporting
- Email notifications / email form processor
- Business calendar
- Rules integration
- web service invocation
- Functional activity types / connectors: SQL, SAP/Abab, file, esb, xml transformation
- Identity pluggability + LDAP implementation
Define PVM event (api)/history event/event (listeners) and map it to BPMN
Configuration, initialization of process engines
Currently there is the strategy of setup building jars containing configurations. There is the programmatic creation of a process engine, there is the ProcessEngines registry and the servlet for automatic initialization.
We should establish a common strategy on how we deal with configuration files and initialization.
Following aspects should be considered and as much as possible unified:
- auto scanning and init and destroy
- basic process engine creation
- support for multiple engines
- ant process engine initialization, caching and destruction. also, how does an ant task reference a process engine
Should the test utilities and APIs be split off into a separate project? Would mean only unit tests in activiti-engine (but that's the way it is now anyway).
- Discuss decision process
- Common 'terminology list'
- OSGi compatibility
- Process class loading
- To what extend can we have a dependency on Spring for core Activiti functionality?
- Naming of Job (name clash with spring Batch)
- Choreography: could it be a way to handle the multiplicity mismatches?
- Work out the cloud example: Elect the next european president, or process the voting for the next eurovision song contest.