Gabriele, Good point, the drools codebase also has Infinispan usage for datagrid use cases...
But as you already pointed out, the surface of those places are much less of a problem if compared to the current infinispan "persistence" modules. On Tue, Apr 1, 2025 at 9:32 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > 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 > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
