Remove any unnecessary dependency from distribution

Description

Not only to reduce the distribution size but also to reduce the vulnerability surface, we should review the dependencies included in the distribution and keep only those strictly necessary to runtime and re-augmentation.

As the server is a mutable jar, these additional dependencies are a trade-off as part of continuous testing support from Quarkus. However, in theory, these dependencies won’t actually be loaded in the runtime application.

Discussion

No response

Motivation

Not only to reduce the distribution size but also to reduce the vulnerability surface, we should review the dependencies included in the distribution and keep only those strictly necessary to runtime and re-augmentation.

Details

Looks like the best approach should be to exclude these dependencies through Maven (instead of using Quarkus properties such as quarkus.class-loading.removed-artifacts).

The proposal is to have a specific profile in the root pom that explicitly excludes the unwanted dependencies. The trade-off here is that we need to make sure the distribution is built using this profile.

[DGuhr]

Hi @trixpan To make it short: I don’t feel offended at all, and I totally understand you w.r.t. 12125 - that was the reason why I avoided to add it to the core when we had the first story around logging showing up and people were asking for it in the discussions.

Your lines above exactly match some thoughts of mine. These thoughts were the reason why I just posted a proposal for a “layered extension framework” to the quarkus-dev mailing list and I would be happy for people interested here to give feedback there (hesitating to open up another discussion here atm, to have one place to get feedback first -> our discussion).

In the end, there was a trade-off to be made:

1. holding back a core integration because the extension story is not that advanced atm, so people have to rely on a totally experimental approach not supported by anything
2. Create a small, easy-to-remove-later-on layer and add the dependencies - at this point in time - to “core”.

I decided to go with option 2, as people were demanding the specific feature and there are holding costs involved (ref)

I consider the core distribution not the right place for the centralized logging extension to rely mid- to longterm, instead it should be an extension for Keycloak, but I consider the current solution to bring value for our users, and to be easily removable later on when we make some significant progress around the extension story.

On a more general level, as I understand your lines, you are touching the decade-long “framework vs library” war here, am I right?

Here’s my view on that: I generally prefer to use plain <programming language> + clearly domain-separated libraries (technical impls) instead of any framework. But: The decision for Keycloak to go with Quarkus was made long ago, even long before I joined, and I can somehow see value in it for a big project that is Keycloak, and especially in the way we did it.

The approach we took provides a loose coupling, actually, because we are loading most parts of the codebase “as is”, without using quarkus interna, into that framework, that is atm “just another” runtime besides Wildfly. We should definitely take care of not coupling too much of our “domain logic” to tightly to the underlying framework. That was, for example, the idea behind the chagnes we made to the config layer - separating general, runtime-independent “Options” keycloak needs from the “PropertyMapper” implementations we use with the specific quarkus property targets (ref). It was first planned to use it as its own independent module, and for now relies in the quarkus namespace just because there is only one impl for it and it somewhat had bad devex implications (you need to build two modules instead of one). Again: Easily extractable later on, and the devex issue can and should be solved. Usable no matter where we evolve to.

On the other hand, when you use a framework, you should definitely use its parts to get the plus of convenience that is the one selling point of frameworks, otherwise you would “work against it”, re-implement parts of its functionality and should just get rid of it. I think we have a good balance here for now. Optimizable? sure.

I hope this answers some of your questions.

[trixpan]

@DGuhr thanks for the write up. I am 100% in agreement with the approach suggested and glad the concerns of community are being taken care of. 😉