I think however this ends up being decided by this list, we should post a conclusion/example/summary/something to the [email protected]<mailto:[email protected]> list so anyone search that list can see the results.
Somewhat related to that, do we want to try to migrate people from the Google Groups list to the users list now that 10.0.0 is released? -- Jason Porter Software Engineer He/Him/His IBM From: Alex Porcelli <[email protected]> Date: Friday, January 10, 2025 at 01:41 To: [email protected] <[email protected]> Subject: [EXTERNAL] Re: [DISCUSSION] ruleflow kjar use case 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 > > >
