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
