+1 to deprecation and eventual removal of infinispan as persistence store Martin
On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote: > I'm +1 to deprecate and exclude the infinispan support from our > deliverables, from the process engine persistence to data-index and > jobs-service (including addons). In this case I think that keeping it for > reference can be useful for users. > > Cheers, > > Pere > > On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti > <ftira...@redhat.com.invalid> wrote: > > > Yes, of course, I'm not worried about history, I'm worried about > > visibility. > > If Infinispan is still there with a deprecation notice, everybody, without > > the need to visit the github log will know that it used to be there and was > > explicitly deprecated. > > And once it is out of the parent module, it won't be bothering anymore. > > Anyway, I don't really care much, we can delete it. > > It's not the first thing I will delete from Apps repo though, Trusty is > > even more bothersome. > > > > > > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <a...@porcelli.me> wrote: > > > > > Thanks for the thoughtful response—I'm glad we're aligned on moving on > > > from Infinispan. > > > > > > That said, I respectfully disagree with the idea of keeping the code > > > in the repository but out of the build. One of the core purposes of > > > Git is precisely to allow us to revisit and recover code from the past > > > if needed. Keeping "dead code" in the codebase creates unnecessary > > > maintenance overhead and potential confusion as the project evolves. > > > > > > If there's a need to bring it back in the future, we can always > > > retrieve it from the commit history or a dedicated tag/branch. For > > > now, I believe removing it entirely is the cleaner and more > > > maintainable approach. > > > > > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti > > > <ftira...@redhat.com.invalid> wrote: > > > > > > > > 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 > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
