Please keep in mind that there are other usages of infinispan scattered throughout our codebase, e.g.
*org.kie.kogito.codegen.process.persistence.PersistenceGenerator* import and uses *import org.infinispan.protostream.FileDescriptorSource;* IMO, until we get rid of all of them , the problem with infinispan binding will remain, anyway it could be that the impact is much more mitigated. M2C Il giorno mar 1 apr 2025 alle ore 14:37 Francisco Javier Tirado Sarti <ftira...@redhat.com.invalid> ha scritto: > I agree to remove Inifinispan, although I have invested a substantial > amount of work to keep it working. > But we have better alternatives for embedded, both relational (embedded > postgresql, h2) and non relational (rocksbd) > Also, it does not have the same level of query support than Mongo and > Postgress (it is not possible to query variables or metadata) > Besides, I also find questionable the original decision to use it as > default data store, given the fact that the optimal use for Inifnispan is > as persistent distributed cache (so, in a way, it was like using Kafka as > datastore, possible, but not its original intent) > I think is good to deprecate it and focus on keeping JPA and mongoDB > implementation at the same level of functionality (currently Mongo is > slightly behind) > Thats said, I think that, rather than removing, we can exclude it (just > remove the reference from the parent POM and keep the code) > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <a...@porcelli.me> wrote: > > > 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 > > > > > > > > > >
