+1 On Tue, 9 Apr 2024 at 12:54, Alex Porcelli <a...@porcelli.me> wrote:
> Glad to hear that! > > +1 > > On Tue, Apr 9, 2024 at 6:48 AM Enrique Gonzalez Martinez < > egonza...@apache.org> wrote: > > > It will land after for sure. > > > > El mar, 9 abr 2024, 12:41, Alex Porcelli <a...@porcelli.me> escribió: > > > > > What about any risk of instability? > > > > > > Looks like we are about 2-3 weeks from be ready to release, is this > > > something that could land just after? > > > > > > > > > On Tue, Apr 9, 2024 at 6:33 AM Enrique Gonzalez Martinez < > > > egonza...@apache.org> wrote: > > > > > > > I dont see any impact as functionality won't change > > > > > > > > El mar, 9 abr 2024, 12:18, Alex Porcelli <a...@porcelli.me> > escribió: > > > > > > > > > Enrique, > > > > > > > > > > How you see this proposal affecting the 10.0.0 release? > > > > > > > > > > > > > > > On Tue, Apr 9, 2024 at 5:35 AM Francisco Javier Tirado Sarti < > > > > > ftira...@redhat.com> wrote: > > > > > > > > > > > Hi Enrique, > > > > > > Thanks for writing down the proposal > > > > > > +10 ;) > > > > > > > > > > > > On Tue, Apr 9, 2024 at 9:50 AM Tibor Zimányi < > tzima...@apache.org> > > > > > wrote: > > > > > > > > > > > > > Hi Enrique, > > > > > > > > > > > > > > thank you, sounds good, +1. > > > > > > > > > > > > > > Best regards, > > > > > > > Tibor > > > > > > > > > > > > > > Dňa ut 9. 4. 2024, 9:21 Enrique Gonzalez Martinez < > > > > > egonza...@apache.org> > > > > > > > napísal(a): > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
