I'd recommend using this :) https://github.com/casehubio/work
Mark On Sun, 16 Nov 2025 at 12:13, Alex Porcelli <[email protected]> wrote: > It sounds like we are aligned on the core idea that having a > WS-HumanTask-based lifecycle available as an optional implementation > can help existing jBPM users transition more smoothly to Kogito, while > preserving Kogito's flexibility and the existing pluggable lifecycle > mechanism. > > To make sure we set the right expectations for users and keep the > contribution complete from a project perspective, I suggest we add two > things before moving the PRs forward: > > - Documentation and an example that shows how to enable and use the > WS-HT lifecycle. This should also make it clear that this is an > optional compatibility implementation, not the default task lifecycle. > - A note in the documentation explains that, although this > implementation facilitates familiar semantics for jBPM users, a direct > drop-in migration is not possible. Existing projects will still > require architectural and code adjustments. Stating this up front > avoids giving users an incorrect impression about the level of > backward compatibility. > > If we incorporate these additions, I'm happy to move forward. > > Thanks again for the constructive discussion. > > > On Fri, Nov 14, 2025 at 9:42 PM Deepak Joseph <[email protected]> > wrote: > > > > Hi Martin, > > I think you are spot on with your comments. That's exactly the reason we > > wanted to support the WS-HumanTask lifecycle for the potential users. I > > agree we could also add an example to depict its usage. > > > > > > > > Regards, > > Deepak Joseph > > > > > > On Fri, Nov 14, 2025 at 3:23 PM Francisco Javier Tirado Sarti > > <[email protected]> wrote: > > > > > Hi Martin, > > > The approach you described sounds good to me. We keep the possibility > of > > > users implementing their own task life cycle as they have now in > Kogito and > > > at the same time we provide a "custom" implementation using the kogito > > > mechanism that follows the WS-HumanTask specification, which will > appeal to > > > those users already using it. > > > Thanks for the clarification. > > > > > > On Thu, Nov 13, 2025 at 10:30 PM Martin Weiler <[email protected]> > wrote: > > > > > > > Thanks for your input, Alex and Francisco! > > > > > > > > You are correct that the WS-HumanTask specification has been around > for > > > > quite a while,. But so has the BPMN specification itself. I don't > think > > > > that this fact alone discredits the fundamental concepts provided by > the > > > > specification. On the contrary, having an implementation that is > backed > > > by > > > > a standard can be beneficial to users from an interoperability > > > perspective. > > > > > > > > As outlined initially, this code is provided as an addition to the > > > > currently provided, simplified lifecycle implementation, and is also > not > > > > interfering with any custom implementations that users might be using > > > > already. Therefore, it is not taking away any of the flexibility > Kogito > > > > provides. > > > > > > > > Of course it could be left to every user interested in the > WS-HumanTask > > > > spec to provide their own implementation. However, as there could > > > > potentially be a number of jBPM users looking to adapt the Kogito > stack > > > > while at the same time preserving some of the flows built around user > > > task > > > > handling, I think it would be a valid and useful addition to the > > > codebase. > > > > > > > > On 2025/11/11 09:49:52 Francisco Javier Tirado Sarti wrote: > > > > > I agree with Alex. > > > > > I believe Kogito flexibility should be more appealing to users > than the > > > > old > > > > > spec. > > > > > So, just to be open, is supporting this spec something some users > are > > > > > asking for? > > > > > > > > > > On Mon, Nov 10, 2025 at 2:53 AM Alex Porcelli <[email protected] > > > > > > wrote: > > > > > > > > > > > Martin, > > > > > > > > > > > > Thank you for bringing this proposal to the mailing list. I have > a > > > few > > > > > > concerns and questions. > > > > > > > > > > > > One of Kogito’s principles was the simplification of the jBPM > stack. > > > > > > The WS-HumanTask specification dates back to the late 2000s with > last > > > > > > updated in 2010, and I recall that it was intentionally removed > at > > > the > > > > > > time, as it was already considered legacy. I’m concerned about > > > > > > introducing or carrying forward legacy concepts into a project > > > > > > designed around cloud-native principles. > > > > > > > > > > > > I’d like to understand better: > > > > > > - What specific use cases require the full WS-HT lifecycle that > > > cannot > > > > > > be achieved with Kogito’s current extensible lifecycle framework? > > > > > > - What is the anticipated long-term maintenance cost of > supporting > > > two > > > > > > built-in lifecycle implementations? > > > > > > > > > > > > Kogito was deliberately designed with pluggable lifecycles. > Users can > > > > > > already implement their own custom lifecycles. Given this > existing > > > > > > extensibility: > > > > > > - What additional capabilities does the WS-HT implementation > provide > > > > > > that are not already possible through extension points? > > > > > > - Will maintaining two built-in lifecycles create confusion for > users > > > > > > about which approach to choose? > > > > > > > > > > > > The proposal also mentions reintroducing a lifecycle “similar to” > > > > > > previous jBPM versions. However, Kogito made deliberate semantic > > > > > > changes that prevent full backward compatibility. I’m concerned > this > > > > > > might lead to incorrect user expectations. > > > > > > > > > > > > Although this discussion ideally should have taken place before > any > > > > > > PRs were opened, since they’re already in place, I want to > ensure we > > > > > > properly address examples and documentation. As this constitutes > a > > > new > > > > > > feature, both are expected as part of the contribution. > > > > > > > > > > > > - > > > > > > Alex > > > > > > > > > > > > On Fri, Nov 7, 2025 at 2:09 PM Martin Weiler <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > Dear KIE community, > > > > > > > > > > > > > > I'd like to draw your attention to an ongoing development that > aims > > > > to > > > > > > > resolve this issue: > > > > > > > https://github.com/apache/incubator-kie-issues/issues/2154 - > Add > > > > support > > > > > > > for WS-HumanTask lifecycle > > > > > > > > > > > > > > This will bring an optional HumanTask lifecycle implementation > to > > > the > > > > > > > workflow runtime that is similar to what existed in previous > jBPM > > > > > > versions. > > > > > > > More details are in the linked issue as well as in the > referenced > > > > PR, but > > > > > > > I'd like to highlight the following points here: > > > > > > > > > > > > > > 1. No changes are enforced to current users. The default > HumanTask > > > > > > > lifecycle currently available in the workflow engine will > remain > > > the > > > > > > > default choice, unless configured otherwise. > > > > > > > 2. A new property "kogito.usertasks.lifecycle" will be added > that > > > > allows > > > > > > > users to chose between the available lifecycles (kogito, > > > > ws-human-task) > > > > > > > 3. The usage of a custom lifecycle implementation is still > possible > > > > as > > > > > > > before. > > > > > > > > > > > > > > Thanks for your attention! > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
