Upgrade from Springdoc 1.6.3 to 1.6.4 causes issues if springdoc-openapi-common is on the classpath but springdoc-openapi-ui is not

[oliverlockwood]

Describe the bug
On application startup, this error:

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 5 of method springDocProviders in org.springdoc.core.SpringDocConfiguration required a bean of type
'org.springdoc.core.providers.SpringWebProvider' that could not be found.

Looking at the changes in this code, this method parameter is clearly newly required in Springdoc 1.6.4.

To Reproduce
Steps to reproduce the behavior:

• Spring-Boot 2.6.2
• Including a library which itself depends on org.springdoc:springdoc-openapi-common
• Not including org.springdoc:springdoc-openapi-ui
• Not explicitly setting springdoc.api-docs.enabled to false

Expected behavior

• The application starts up fine, as it did with Springdoc 1.6.3

Further notes
I can resolve this by explicitly setting springdoc.api-docs.enabled to false, but I thought to raise the issue in case:

• other people hit this issue and find it helpful having the resolution highlighted, and/or
• this change was not intentional and the maintainers would like to adjust the library behaviour.

[bnasslahsen]

@oliverlockwood,

I have added a fix for this.

But the original question, is why you are using: springdoc-openapi-common only. There is nothing in the documentation, that asks for referencing this dependency alone.
In general, you should be using at least webmvc or webflux.
Would be interesting to know your use case for using springdoc-openapi-common only.

[oliverlockwood]

Thanks @bnasslahsen.

Yes, I'd be happy to explain.

In our project, we have the following modules:

• Common, which defines APIs and model POJOs, which are annotated using annotations from springdoc-openapi-common accordingly.
• Service, which depends on Common, and provides Controller implementations of the APIs, and includes the springdoc-openapi-ui library, and exposes the OpenAPI documentation accordingly
• Client, which depends on Common, and uses Feign to provide client implementations of the APIs defined therein
• AcceptanceTests, which runs Cucumber-JVM ATs against a running Docker container of the service, and depends on Client to easily use the APIs exposed by the service.

Thus the AcceptanceTests module transitively depends on Client --> Common --> springdoc-openapi-common, but it does not make sense for the AcceptanceTests module to include springdoc-openapi-ui, since there are no meaningful APIs exposed by the application which runs the Cucumber-JVM ATs.

Hope that clarifies the use-case.

[bnasslahsen]

@oliverlockwood,

i see and makes sense!
Thank you for your clarification.