Hi Alex, the drop of legacy runtime is something discussed and approved in the mailing list long ago.
El vie, 10 ene 2025, 9:41, Alex Porcelli <[email protected]> escribió: > Thank you, Toshiya, for bringing this up to ML. > > For context, I’d like to remember that there are no Drools or jBPM; both > are components of Apache KIE. > > As of today, Apache KIE 10 supports kjar; Toshiya's example proves that. > Therefore, this could be considered a bug, not a new use case. > > Enrique, regarding parity between runtimes, it’s not necessary to provide > the same level of feature support for all of them, so the scope of rule > flow could be narrowed. > > What I believe we can’t do is be dysfunctional and force drops of major > features after a major release without a proper heads-up or an alternative > path. > > - > Alex > > On Fri, Jan 10, 2025 at 12:10 AM Enrique Gonzalez Martinez < > [email protected]> wrote: > > > Hi toshiya > > > > Kjar is not supported in workflow as the main focus is codegen. > > Supporting in memory compilation would lead us to support two different > > runtimes and integration with drools. > > At this point it might be working because the legacy runtime is still > there > > but any attempt to support this in kogito will get pushed back as we are > > removing thr old runtime therefore kjar wont work. There are several > > reasons for it. From how big the effort would be to parity features in > both > > runtimes. > > So the answer is no. We should not. > > > > El vie, 10 ene 2025, 4:20, Toshiya Kobayashi <[email protected] > > > > escribió: > > > > > Hello, > > > > > > Since Drools 8, in other words, since jBPM was moved into Kogito, the > > > ruleflow (drl + bpmn) kjar use case has been dropped, because Kogito > > > doesn't support kjar. A user is facing a migration problem ( > > > > > > > > > https://kie.zulipchat.com/#narrow/channel/232677-drools/topic/Errors.20when.20moving.20from.20last.20Drools.207.20release.20to.20drools.208 > > > ) > > > > > > The combinations may sound confusing. > > > > > > - drl + bpmn in kogito service is supported. (See > process-quarkus-example > > > in incubator-kie-kogito-examples) > > > - drl in kjar is supported (See kie-maven-plugin in > incubator-kie-drools) > > > - drl + bpmn in kjar is the topic of this thread > > > > > > I created an example with KIE 10.0.0 + drl + bpmn + kjar. > > > > > > > > > > > > https://github.com/tkobayas/kiegroup-examples/tree/master/Ex-ruleflow-10.0.0 > > > (Adding org.kie.kogito:jbpm-bpmn2 dependency) > > > > > > ``` > > > mvn clean install -DskipTests > > > mvn test > > > ``` > > > > > > It seems to work fine so far. (It has an issue with "import" handling, > > but > > > I worked around it using FQCN. It's another story...) > > > > > > Having said that, shall we revitalize the ruleflow kjar use case? > > > > > > I think of these points: > > > > > > 1. Confirm the supported scope : No persistence. Limited nodes (Start, > > End, > > > Rule, Gateway?) > > > 2. Consult jbpm developers because the new jbpm has been targeted only > > for > > > kogito service use cases (= requires quarkus or springboot, and depends > > on > > > codegen. Am I correct?). Any caveats to support kjar? > > > 3. Create test cases in kogito-runtimes? > > > > > > Especially, about 2... Any concern about supporting kjar with jbpm (= > > > org.kie.kogito:jbpm-bpmn2)? > > > > > > Cheers, > > > Toshiya > > > > > >
