we prefer the jBPM approach as well :-) And I agree completely with your analysis. The only thing which is also to be considered by us as a software vendor is adoption. Meaning that when we go out to compete against other solutions, often the decision makers are not always the ones to which you can explain all this. If then, you have to compete with other engines that have the BPMN 'checkmark', it may become hard. Our current strategy is to work out our own notation for jPDL in our own eclipse plugin designer. We'll keep a close eye on what the BPMN and other editors do in eclipse land mainly in terms adoption. If BPMN would get mainstream adoption, we might have to switch or support both. Another option that we want to keep open is the usage of layered BPMN. Meaning that you could define a subset of BPMN wich corresponds pretty much with what we have now in our jPDL editor. Then the tool could be limited to this subset. Then the subset could be enlarged by adding a next set of BPMN constructs... until you have the full BPMN constructs set. That might be another approach to get the best of both worlds. The swimlane remark is certainly right on. Currently, we have been reluctant because our process language alowes multiple tasks in one task node. Then all of these tasks might potentially be assigned to different swimlanes. But we should at least go for swimlane support and just fix that problem. Either by limiting task-nodes in a swimlane to max 1 task. Or by just taking the first task into account for the swimlane representation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992288#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...