I agree to plan the component deprecation and then its removal in a future release.
On 2025/04/02 22:32:25 ricardo zanini fernandes wrote: > Please +1 to deprecate. We can push for another tech stack in the future, > like Redis, if necessary. Currently, ISPN in our codebase is bringing more > harm than good. The tradeoff is not worth it IMO. > > On Wed, Apr 2, 2025 at 1:36 PM Jason Porter <lightguar...@apache.org> wrote: > > > I have very little skin in this game, but I am also +1 for deprecation and > > removal. This will simplify what we need to support, examples (we'll have > > to make sure those are looked at, as well as documentation), and should > > also make maintenance easier. > > > > On 2025/04/01 23:05:02 Martin Weiler wrote: > > > +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 > > > > > > > > > > --------------------------------------------------------------------- > > 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
