In the case of the Italian National ID Federation plugin, (https://github.com/italia/spid-keycloak-provider), we rely on server-spi-private for reusing many of the SAML-related types and features - the expected custom SAML dialect only has a handful of differences compared to standard SAML. Currently plugin builds for Keycloak v19 fail as the server-spi-private package no longer marks the dependency as provided. I can work around this by supplying an explicit dependency, but then I have to match the library version in my pom instead of just using whatever Keycloak is providing. This is less than ideal.
Would it be possible to restore the previous behaviour?
Any additional ideas or workarounds are welcome.
Perhaps we could try scoping it to test. I don't recall the exact point of failure, but there was some dependency issues that where difficult to trace.
Description
Commit https://github.com/keycloak/keycloak/pull/13489/commits/0be98f2a57d60b5fc79f8a72eff2ab168a0c36ae from @david-rh removed the
<provided>
attribute from theorg.apache.httpcomponents.httpclient
dependency in moduleserver-spi-private
, seemingly as a convenience feature for testing. However this causes an issue when building custom SAML-derived providers.In the case of the Italian National ID Federation plugin, (https://github.com/italia/spid-keycloak-provider), we rely on
server-spi-private
for reusing many of the SAML-related types and features - the expected custom SAML dialect only has a handful of differences compared to standard SAML. Currently plugin builds for Keycloak v19 fail as theserver-spi-private
package no longer marks the dependency as provided. I can work around this by supplying an explicit dependency, but then I have to match the library version in my pom instead of just using whatever Keycloak is providing. This is less than ideal.Would it be possible to restore the previous behaviour? Any additional ideas or workarounds are welcome.