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]
