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