There is a mirror argument, there is stuff in quarkus that might be located in common, but that is probably less urgent and easier to move.
On Fri, Apr 4, 2025 at 2:16 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Ok, so 1) becomes "extracting quarkus code that should have never been > there from common stuff" > > On Fri, Apr 4, 2025 at 1:48 PM Enrique Gonzalez Martinez < > elguard...@gmail.com> wrote: > >> Maybe the data index is not but in the job service they depend on reactive >> code for quarkus >> >> El vie, 4 abr 2025, 12:56, Francisco Javier Tirado Sarti >> <ftira...@redhat.com.invalid> escribió: >> >> > Hi Enrique, >> > I think is a good initiative, but we need to work on the details ;) >> > So let's start with 1), which are the common components? I'm asking >> because >> > besides IT test that are put in common modules and should be moved to >> > platform ones, there is not stuff belonging to sprinboot or quarkus in >> core >> > modules. >> > >> > On Fri, Apr 4, 2025 at 12:18 PM Pere Fernandez (apache) < >> > pefer...@apache.org> >> > wrote: >> > >> > > + 1 to that! >> > > >> > > On Fri, 4 Apr 2025 at 09:54, Alex Porcelli <a...@porcelli.me> wrote: >> > > >> > > > Thank you for this initiative, Enrique! >> > > > >> > > > +1, big time! >> > > > >> > > > - >> > > > Alex >> > > > >> > > > On Fri, Apr 4, 2025 at 2:29 AM Enrique Gonzalez Martinez < >> > > > egonza...@apache.org> 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 >> > > > > >> > > > > >> > > > >> > > >> > >> >
