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 > >
