This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality.

First of all, congratulation for getting out the long awaited release - well done. I got the download from SF, installed the GPD, read the docs, had a look at the API and generally tried a few things - here my impressions. May it be helpful ;-) The new graphical designer (GPD) looks really nice. It finally adopts the BPMN standard for its graphical elements, which looks really nice. There is the notion of start event, and end event, a few gateway types and a significant number of tasks. What is a little bit confusing is some inconsistency in the terminology that is being used in the GPD, the docs and the API. BPMN talks about exclusive, inclusive, parallel and complex gateways. These have a specific semantics and everybody who knows BPMN would also know their semantics. GPD on the other hand talks about exclusive, fork, join The jbpm4 docs sais anonymous wrote : | (BPMN note: when we mention activities here, we are not only refering to BPMN activities, but also to BPMN events and BPMN gateways.) | If possible, I would not do that. An activity is an activity (namely a task or a sub-process), an event is an event, a gateway is a gateway. jBPM4 allows multiple outgoing flows on a task. This combines the notion of task with the notion of gateway. It is however not clear what type of gateway is being combined here and if we assume that it is an exclusive gateway, it not clear whether the full functional set of an exclusive gateway is also available on the task. Can every task have multiple outgoing flows? I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR) The docs talk about "end state" - this should be "end event" - cancel and error are "event details" that if attached to an end event are called "result" Generally, I'd recommend not to invent new terminology for a concept in the BPMN editor that already has a "standard" name in BPMN. Also don't use existing BPMN terminology to mean something different. The API combines the notion of ProcessInstance with that of Token in a single interface and calls it "Execution". This will not allow these two concepts to evolve independently for example when you want to add state independently to the ProcessInstance and the Token. It is generally better to model a concept like ProcessInstance as such and call it by it's name. If you cant do much (yet) with a ProcessInstance you will have a short method list, which is ok. The GPD elements in the process definition should be defined in their own namespace Instead of | <start g="32,22,80,40"> | jBPM should have | <start gpd:g="32,22,80,40"> | This allows GPD metadata to evolve independently of the process definition itself and also makes it clear that 'g' is a presentational and not a functional element. During GPD installation, the license text is missing. This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality. Thanks for Alpha1, I'm looking forward to stuff to come. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201795#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a... _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev