All parsers build on top of jbpm flow engine: swf, bpmn and cmmn will share the same set of the dependencies (those ones of jbmp-flow) jbpm-flow currently has a dependency on kogito-dmn because of RuleSetNode. If we move that node to a separate module, parsers that do not use drl/dmn will not have this module in their dependency set. kogito-dmn dependency is currently marked as optional in the jbpm-flow module just to avoid including it, but this was a "hack"
On Wed, Apr 10, 2024 at 12:55 PM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > The ideas was to move the things that are not primitives to bpmn module. > Included dmn. > > Why do you want to create a new module ? Shared concern ? > > El mié, 10 abr 2024, 11:46, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Hi, > > A minor detail I just realized is, can we include in the proposal the > > target module for RuleSetNode (the one used for drl/dmn execution)?. I'm > > assuming it will no longer be jbpm-flow. I propose a module named > > jbpm-flow-dmn-extension or similar. > > > > On Tue, Apr 9, 2024 at 10:31 PM Jason Porter <lightguar...@apache.org> > > wrote: > > > > > +1 for this idea. Future proofing our tech is certainly a good idea! I > > > think this could also lead to some consolidation of code in the future, > > if > > > I understand correctly. > > > > > > On 2024/04/09 07:21:30 Enrique Gonzalez Martinez wrote: > > > > At present, it is very difficult adding new nodes and new states to > > > > the workflow engine. > > > > > > > > In the medium/long term, additional node types that only serve > certain > > > > requirements will be needed. The reasons for adding them can be > really > > > > different and they might only be useful in certain situations or > > > > process definitions. > > > > > > > > The idea of the proposal is to create a set of extension points for > > > > making the engine more reusable and allow other process definitions > > > > add their own node types and execution types without polluting the > > > > engine with basic primitives of execution. > > > > > > > > This will have an impact at three different levels. > > > > > > > > * Add capability to create node instances (node states) from the > > > > nodes. This will impact the NodeInstanceFactory. > > > > * Add capability to store that node instance This will impact the > > > > marshaller and unmarshaller > > > > * Add capability to extends the flow builder to allow code generation > > > > > > > > As the responsibility of compiling into an intermediate > representation > > > > relies on parser, that should not impact other modules. > > > > This will allow a clear boundary among compilers and a clean > > > > responsibility among modules to accept new features. > > > > > > > > This is a general idea of how this would look at the end: > > > > > > > > > > > > * jbpm-flow: > > > > - will contain the compiled process definition > > > > - will contain the execution algorithm > > > > - primitive nodes that cannot break down into smaller pieces > > > > > > > > * jbpm-marshaller > > > > - contains the extension point for new nodes. > > > > > > > > * jbpm-flow-builder > > > > - contains the extension point for generating code. > > > > > > > > * jbpm-flow-bpmn2-extension > > > > - will contain nodes related exclusively to bpmn2 like human > task > > > > or ruleset > > > > - contains marshall/unmarshalling logic for the new nodes > > > > > > > > * jbpm-flow-bpmn2-builder-extension > > > > - contain logic for code generation > > > > > > > > * jbpm-flow-cmmn-extension > > > > - nodes related to cmmn like sentries, plan, stages, > > milestones.... > > > > - contains marshall/unmarshalling logic for the new nodes > > > > > > > > * jbpm-flow-cmmn-builder-extension > > > > - contain logic for code generation > > > > > > > > * jbpm-flow-swf-extension > > > > - will contain any special/optimized node for serverless > workflow > > > > execution. > > > > - contains marshall/unmarshalling logic for the new nodes > > > > > > > > * jbpm-flow-swf-builder-extension > > > > - contain logic for code generation > > > > > > > > As this is considered a Java component the mechanism to be used would > > > > be the service loader approach without relying on any runtime like > > > > quarkus or spring boot. > > > > > > > > This impact in the code should be rather small in this case but allow > > > > more independency around working on process definitions > > > > implementations (swf, bpmn2 or event future cmmn) > > > > It reduces the friction among process definition implementations > > > > It allows to focus in implementation details of process definitions > > > > instead of changing primitives in the workflow engine causing > > > > unnecessary changes. > > > > > > > > > > > > > > > > Cheers :) > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > >
