Ok, thanks! Il giorno mar 1 apr 2025 alle ore 15:54 Alex Porcelli <a...@porcelli.me> ha scritto:
> 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 > >
