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 >
