Ok, thanks! Il giorno mar 1 apr 2025 alle ore 14:00 Alex Porcelli <a...@porcelli.me> ha scritto:
> I think those interfaces are already in place - at some extent. We have a > few different db implementations already: mongo, Postgres, rocksdb; so I’d > suspect that it should be enough for now. > > I also would argue that H2 is also a reasonable solution for in-memory with > low cost and is now actively used in jBPM when running in dev mode. > > - > Alex > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi < > gabriele.card...@gmail.com> > wrote: > > > HI Alex, > > I agree with your concern. > > I do not know exactly where and why infinispan is used, but I also hit > > issues with it during some upgrades. > > From my POV the issue is that > > 1. On one side, we want to provide in-memory support for our > applications, > > which is a good feature > > 2. on the other side, we implemented specific solutions, with > hard-binding > > to that specific implementation (infinispan), that lead to the issue you > > mentioned > > > > Being everything open source, maybe a good solution would be to design > and > > provide API/interfaces for any "in-memory" database, and then whoever > wants > > to create a specific implementation, outside our apache-kie project, > would > > still be able to create it. > > > > Wdyt ? > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli < > porce...@apache.org > > > > > ha scritto: > > > > > As part of the ongoing effort to upgrade to the latest Quarkus LTS > > version, > > > we’re currently dealing with the impact of aligning with Infinispan 15, > > > which introduces a new set of changes and potentially api compatibility > > > issues. > > > > > > Given this context, I’d like to revisit the question: Do we really want > > to > > > continue supporting Infinispan? > > > > > > This has been discussed in the past, and there was some resistance to > > > removing it. However, maintaining support goes beyond the existing > > > implementation—it requires us to stay on top of future upgrades, adapt > to > > > API changes, and deal with potential security vulnerabilities stemming > > from > > > Infinispan itself and its transitive dependencies. > > > > > > I believe it’s worth re-evaluating its value and whether it’s aligned > > with > > > the future direction of the project. > > > > > > Looking forward to your thoughts. > > > > > > - > > > > > > Alex > > > > > >