I raised a thread on zulip [1] proposing a call to move forward with this issue. However, it was pointed out that this is not in the spirit of Apache guidelines for resolving issues. Therefore, I'd kindly ask that we continue the discussion that has happened in the PR [2] so that we can unblock this situation and reach the goal of getting the codebase ready to support Springboot in both data-index and jobs-service as agreed on earlier in this thread.
Thanks! [1] https://kie.zulipchat.com/#narrow/channel/382044-kogito-dev/topic/Jobs.20service.20-.20Springboot.20readiness/with/515793534 [2] https://github.com/apache/incubator-kie-kogito-apps/pull/2214 On 2025/04/26 08:37:53 Enrique Gonzalez Martinez wrote: > A bit more context. > > Features are different from infra being used. Reactive code does not affect > feature only how they are implemented. This reactive code is preventing us > to reuse code among runtimes and create a different job service is > unsustainble so that option is off the table. > About impacting sontata flow your are not correct in any way. The subsystem > will keep its features. > > Please next time when a discussion about changes occure try to jump in at > the right moment. > > Saludos, Enrique González Martínez :) > > El sáb, 26 abr 2025, 10:34, Walter Medvedeo <wmedve...@apache.org> escribió: > > > Hi Enrique, > > > > approved what? to change the architecture of a service that is Reactive, > > to a non Reactive one? > > > > I don't see where this is approved or even mentioned. > > > > > > > > On 2025/04/26 08:23:37 Enrique Gonzalez Martinez wrote: > > > Hi walter this is out of date and therefore approved. > > > We are not removing features in any way. > > > > > > El sáb, 26 abr 2025, 9:06, Walter Medvedeo <wmedve...@apache.org> > > escribió: > > > > > > > For example, > > > > I have just seen this PR > > > > https://github.com/apache/incubator-kie-kogito-apps/pull/2214 that > > > > removes the JS reactive code, and that has a direct impact on all the > > > > current SonataFlow installations. > > > > > > > > > > > > > > > > On 2025/04/26 06:51:54 Walter Medvedeo wrote: > > > > > Hi Enrique, > > > > > > > > > > As you know, the compact architecture, is only one of the > > architectures > > > > supported by the project, but no the only one. I fact, we have many > > user > > > > installations on top of the "non compact architecture". So, any > > potential > > > > refactoring, etc., must keep that in mind. > > > > > > > > > > In step 4), when you say "remove all features that are not shared > > among > > > > runtimes or they are > > > > > incompatible among runtime": > > > > > > > > > > Could please enumerate which features are you referring too? i.e, > > > > targeted for removal. > > > > > > > > > > -1 to feature removals that are not clearly notified and agreed with > > the > > > > team. > > > > > > > > > > Regards, > > > > > Walter. > > > > > > > > > > > > > > > On 2025/04/04 07:29:45 Enrique Gonzalez Martinez wrote: > > > > > > Hi guys, > > > > > > > > > > > > Most of you are aware that the configuration supported by the > > project > > > > > > (the compact architecture) only is supported by quarkus and not SB. > > > > > > This might impact the project adoption in one of the most used > > > > > > microservice frameworks (or standard de facto) for building > > > > > > microservice. > > > > > > > > > > > > The one thing stopping us from supporting this runtime in compact > > > > > > architecture is these components that require some attention. > > > > > > > > > > > > We already have patterns on how to deal with this sort of problem. > > > > > > (multiple runtime support), so ideally is to use them to upgrade > > these > > > > > > components to use those and add support for the runtime. Basically > > > > > > would be > > > > > > > > > > > > 1. identify the common components and isolate properly without any > > > > runtime use. > > > > > > 2. minimize the codebase deployed in runtime (should be a thin > > layer) > > > > > > 3. Move the generic tests to the common components and integration > > > > > > test to the runtimes components) > > > > > > 4. remove all features that are not shared among runtimes or they > > are > > > > > > incompatible among runtimes to avoid code duplication and therefore > > > > > > reduce the sustaining effort. > > > > > > > > > > > > Let me know your thoughts. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
