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
