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]
