Solving quarkus-cache split package issues #44154
gsmet
started this conversation in
Design Discussions
Replies: 3 comments 2 replies
-
I would go with two and change to CDI. If I remember correctly, the SPI was extracted from the initial Cache implementation (Caffeine). With requests for multiple cache backends simultaneously, it seems a good time to revisit this. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Totally - this what we do in most places |
Beta Was this translation helpful? Give feedback.
0 replies
-
Also +1 for option 2 - CDI integration. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
quarkus-cache
andquarkus-cache-runtime-spi
share a common package:io.quarkus.cache
.This is problematic and should be solved as we know split packages lead to all sort of issues and are not future-proof - see for instance #34776 .
There are multiple strategies to solve this (I put aside the backward compatibility fixes that will have to be solved with a transition period):
quarkus-cache-runtime-spi
toio.quarkus.cache.spi
. But that meansCache
- which is an object consumed by end users - will be underio.quarkus.cache.spi
which looks odd. That's the easiest way to sort out this situation but it doesn't look very appealing to me.CacheManagerInfoBuildItem
and theCacheManagerInfo
->CacheManager
->Cache
dependency./cc @gwenneg @mkouba @cescoffier @geoand
Beta Was this translation helpful? Give feedback.
All reactions