не запилят. спрингфокс мертв

вот ему на смену
https://github.com/springdoc/springdoc-openapi

надо бы кстати подтянуться и написать плагин под него сразу к zuul и scg

этот кстати умеет в webflux

Кажется, да, правда, чуть ниже - жирным шрифтом:

spring-webflux with Functional Endpoints, will be available in the future release

А может им просто написать про gateway?

spring-webflux with Functional Endpoints, will be available in the future release

А что functional endpoints? Там другой мир как бы и под него надо отдельно пилить интеграцию без аннотаций)

spring-webflux with Functional Endpoints, will be available in the future release

Ну напиши, не думаю что они сделают, в мире стопятьсот апи гейтвеев, под каждый они писать не будут

Так ведь и gateway'евский RouteLocator тоже функциональный, без аннотаций. Где-то видел вариант, китаец использовал описание в application.yml и туда же впихивал конфиг для сваггера

так речь не об этом, речь об аннотаировании контроллеров, апи сервисов, RouteLocator просто сделан на реакторе там и всего навсего

В проекте в депенси используется библиотека(spring-cloud-contract-stub) - которая использует другую библиотеку(wiremock-standalone), в которой есть скомпиленный класс org.something.UsefullClass
также в проекте есть другая библиотека(spock) - которая использует одну библиотечку(opentest4j) именно как библиотеку, и в ней находится класс`org.something.UsefullClass` и этот класс новее с дополнительными методами по сравнени с первым вариантом этого класса из другой библиотеки
и по-этому вместа нормального ответа на поломаных тестах, иногда выкидывается ересь и содомия.

Как лучше данную ситуацию разрулить ?

единственная идея что приходит в голову это написать какой-то гредл таск который в момент сборки  выпиливает этот первый класс

может что-то менее грязное есть ?

в мавене просто exclude указать для клауд стаба

Народ, а в какой момент вы у себя в проектах поднимаете и деплоите версии api/lib? По комиту там или руками когда готов релиз кандидат

Не стал сразу предлагать exclude, потому что речь не о разных версиях одной библиотеки, а о двух разных библиотеках, которые внезапно содержат (почему?) одноименные пакеты. Первая относится к зависимостям самого проекта, вторая — тестов, как я понял по этой причине сия коллизия не валит билд. Я бы попробовал исключить wiremock-standalone в тестовом конфиге.

именно в этом и проблема - я вот сейчас пытаюсь докопатся откуда в wiremock-standalone этот класс лежит как класс

если отключаю, то завязанные на wiremock тесты падают - если, не выключаю то тесты работают, но если тест падает, изредка  выдают очень эпичный стектрейс вместо того чтобы писать какой ассершен упал

может этот самый wiremock-standalone когда собирается используется какой-нибудь shadowing и из-этого там этот класс и получается что лежит как класс

картина Репина - как найти эпичную граблю и вступить на неё =)