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] > > > > >
