Thanks, guys.
I searched https://groups.google.com/g/kogito-development , but I cannot
find the discussion about kjar. Anyway, Kogito hasn't supported kjar from
the beginning, so it's a very old story.
Having said that, options seem to be:
A) Create a small subset of bpmn parser and engine (apart from the kogito
bpmn code base), which aims at only ruleflow (Start, End, Rule, Gateway).
pros: Users can use the existing bpmn editor to author ruleflow bpmn
files.
No need for a migration tool.
cons: It will likely have some duplication with the kogito bpmn code base.
B) Create a new feature to support ruleflow. e.g. only changing
ruleflow-group with/without conditions. It may or may not be like .rf file
* Note: This option's pros and cons are ambiguous as the details are not
yet defined
pros: The implementation may be smaller than bpmn
cons: Developing a migration tool would require some effort. (or no
migration tool)
Developing an authoring UI tool would require some effort. (or no
authoring tool)
C) Just guide how to migrate ruleflow to drl and java code.
pros: No additional development
cons: Probably it's not possible to create a migration tool. It may
require a large effort if a user has lots of ruleflows
Any thoughts?
Toshiya
On Mon, Jan 13, 2025 at 6:13 PM Enrique Gonzalez Martinez <
elguard...@gmail.com> wrote:
> Jason,
> At the moment we dropped support for legacy runtime kjar is not a supported
> scenario in workflow.
>
> El vie, 10 ene 2025, 17:24, Jason Porter <jpor...@ibm.com.invalid>
> escribió:
>
> > I think however this ends up being decided by this list, we should post a
> > conclusion/example/summary/something to the us...@kie.apache.org<mailto:
> > us...@kie.apache.org> 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 <porce...@apache.org>
> > Date: Friday, January 10, 2025 at 01:41
> > To: dev@kie.apache.org <dev@kie.apache.org>
> > 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 <
> > egonza...@apache.org> 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 <
> toshiyakobaya...@gmail.com
> > >
> > > 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
> > > >
> > >
> >
>
