it is indeed true that some efforts for patterns are only supported in xml parsing. up until now, this didn't give any problems because the patterns-only node constructs were not documented and hence nobody knew about the existence. i didn't yet remove them completely because i aimed at showing that with jbpm, we can handle any pattern. if it doesn't yet exist, we can simply implement it. the only thing that we have to take care of is that the runtime data structures support all the patterns. looking at the future, i think that we want to show that the process virtual machine (rebranding of graph oriented programming) is a runtime data structure that can support all patterns. we can develop a separate language for showing this. which isolates our patterns efforts from the jPDL language. wether we should rip out the patterns nodes from the xml parsing, i don't know. i am not against it, as long as this isn't interpreted as: we give up on patterns. script in fork is not persisted in the 3.1.x because this breaks db compatibility. you can make it work in your installation by adding the many-to-one in the fork for the script field. this is what has been fixed in HEAD of cvs for 3.2.x releases. generic mechanism of conditions on transitions is certainly something that i anticipate for 4.0. as at would result in a big effort of explaining these changes in the 3.x releases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979982#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...