Stemming from a previous discussion I want to discuss JBPM-2414 separately. The original proposal in the jira issue showed a foreach activity separate from fork. At some point the collection iteration behavior got merged into fork for no reason other than "making it visible in the designer, now". In my view, the foreach and the fork behaviors respond to different needs and should not be merged.
As precedents, I can think of BPEL 2 and its flow and forEach activities. The former provides static parallelism of multiple activities. The latter provides dynamic parallelism of a single activity; nothing prevents this single activity from being a flow. Giving each activity a single responsibility makes its behavior concise and simple to describe.
I suggest we introduce a separate foreach activity instead of adding iteration semantics to fork. The binding and activity code that Maciej wrote is kept intact. Only one outgoing transition is allowed. The transition condition MAY refer to the variable specified in the var attribute. If the transition condition evaluates to false, the corresponding child execution does not leave the activity. If no child execution leaves the activity, an exception is thrown.
<foreach name="multiplier" var="item" in="#{items}">
<transition to="task" name="to_task" expr="#{item.value > 10}"/>
</foreach>
I am going to prepare a patch with this proposal and attach it to JBPM-2414 for your review.