You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently I am unable to use both spring-boot 5.1.0.M1 (with JAX-RS setup) and swagger-core 2.0.3 / swagger-jaxrs2 2.0.3 because swagger declares dependencies for such libraries like snakeyaml which (! think of it) ONLY needed ONCE when the app starts (to be more precise - when you first time access the swagger endpoints) BUT forces whether usage of compatible libraries versions or simply not using 5.1.0.M1 or swagger itself.. which seems very very obligative and tightening. As in this particular case spring boot 5.1.0.M1 uses 1.2+ version of snakeyaml and swagger - 1.18 and they are not compatible.
this would be quiet consistent to embed, repackage them and shade as they are needed for internal usage not to invent the bicycle but right now this regard seems completely out of proper setup as it literally forces a version regardless does one-time job for to generate openapi desc.
I would also extend the issue to the fact that it uses Jackson the same way, and the same logic as I expressed above relevant to jackson libraries as well, It already has a certain amount of confusion from users when you have swagger's ObjectMapper which is also "a kind of" configurable but those configurations are not intuatively limited to a subset as only such as naming strategies and some other settings would apply and not serialization/deserialization which are only runtime modifications, of course. But again this is not intuitive. Maybe create a wrapper around Jackson's ObjectMapper and expose just some relevant settings in swagger spesific more descriptive way etc.
embed, repackage them and shade SnakeYaml
2*. same + wrap with own API for Jackson (ObjectMappers for dataformats (Json and Yaml) as I remember) - this one is not the core of this issue, so less relevant.
The text was updated successfully, but these errors were encountered:
Swagger could produce an alternate shaded dependency (with the shaded classifier) for those that need it. We ended up building one for ourselves internally. It's unfortunate that we have to do it ourselves.
Currently I am unable to use both
spring-boot 5.1.0.M1
(withJAX-RS
setup) andswagger-core 2.0.3
/swagger-jaxrs2 2.0.3
because swagger declares dependencies for such libraries likesnakeyaml
which (! think of it) ONLY needed ONCE when the app starts (to be more precise - when you first time access the swagger endpoints) BUT forces whether usage of compatible libraries versions or simply not using5.1.0.M1
or swagger itself.. which seems very very obligative and tightening. As in this particular casespring boot 5.1.0.M1
uses1.2+
version ofsnakeyaml
and swagger -1.18
and they are not compatible.this would be quiet consistent to embed, repackage them and shade as they are needed for internal usage not to invent the bicycle but right now this regard seems completely out of proper setup as it literally forces a version regardless does one-time job for to generate openapi desc.
P.S. stacktrace
I would also extend the issue to the fact that it uses Jackson the same way, and the same logic as I expressed above relevant to jackson libraries as well, It already has a certain amount of confusion from users when you have swagger's
ObjectMapper
which is also "a kind of" configurable but those configurations are not intuatively limited to a subset as only such as naming strategies and some other settings would apply and not serialization/deserialization which are only runtime modifications, of course. But again this is not intuitive. Maybe create a wrapper aroundJackson
'sObjectMapper
and expose just some relevant settings in swagger spesific more descriptive way etc.SnakeYaml
2*. same + wrap with own API for
Jackson
(ObjectMapper
s for dataformats (Json
andYaml
) as I remember) - this one is not the core of this issue, so less relevant.The text was updated successfully, but these errors were encountered: