Solving quarkus-cache split package issues

[gsmet]

quarkus-cache and quarkus-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):

1. Adjust the root package of quarkus-cache-runtime-spi to io.quarkus.cache.spi. But that means Cache - which is an object consumed by end users - will be under io.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.
2. Adjust the SPI - I'm not sure passing objects that references types that are user-consumed in the build item was a good idea. Shouldn't we use CDI integration instead? There might be good reason to do it the way it was done but, given the issues we have now, I'm not sure it was a good idea. I don't have the full background that led to this choice though. My problem is with the CacheManagerInfoBuildItem and the CacheManagerInfo -> CacheManager -> Cache dependency.

/cc @gwenneg @mkouba @cescoffier @geoand

[cescoffier]

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.

[geoand]

Shouldn't we use CDI integration instead?

Totally - this what we do in most places

[mkouba]

Also +1 for option 2 - CDI integration.

[gsmet]

It would be nice if you could create an issue with the overall plan. I think we could find someone else to implement it but you're the obvious person to design where we want to go and the big picture plan.

Maybe also having in mind what @cescoffier was mentioning about supporting multiple cache backends.

[mkouba]

Hm, it seems to be even more tangled. We have SPI and quarkus-caffeine but still quarkus-cache contains the Caffeine implementation of the SPI?

[mkouba]

With requests for multiple cache backends simultaneously, it seems a good time to revisit this.

Ok, so I looked at the implementation and multiple backends are actually supported since 3.29: #50007.

Anyway, in the context of #48688 - shouldn't we rename quarkus-cache-runtime-spi to quarkus-cache-runtime-api and move all classes from the io.quarkus.cache package to this artifact? Optionally, we could rename the io.quarkus.cache to io.quarkus.cache.api... but that's obviously a breaking change.

@gsmet @cescoffier @geoand WDYT?

[mkouba]

Ah, wait a minute. It's necessary for the quarkus-cache-deployment-spi...

[mkouba]

But given the fact that deployment modules always depend on runtime modules... quarkus-cache-deployment-spi probably does not make a lot of sense either 🤔.

[mkouba]

Ok, so the quarkus-cache-deployment-spi contains three build items.

AdditionalCacheNameBuildItem and CacheTypeBuildItem can be used by other extensions to (1) register a cache of the specified name (no annotations used) and (2) detect if the cache backend is local/remote. Both were introduced because of qute and {#cached}. And it makes sense because quarkus-qute may live without quarkus-cache. If no local cache is present then {#cached} is simply disabled.

For CacheManagerInfoBuildItem (which depends on runtime-spi) it IMO does not make a lot of sense to place this build item in the SPI because extensions that produce this build item inherently depend on quarkus-cache.

I would be in favor of this solution:

1. Move the classes from the quarkus-cache-runtime-spi artifact to quarkus-cache
2. Get rid of the quarkus-cache-runtime-spi
3. Move CacheManagerInfoBuildItem to the quarkus-cache-deployment

[geoand]

Sounds reasonable to me

[mkouba]

FYI #50615