Ⓢ
или добавить <configOptions>...<interfaceOnly>true</interfaceOnly>
Size: a a a
2018 November 07
2018 November 08
MV
или добавить <configOptions>...<interfaceOnly>true</interfaceOnly>
Да, это оно, но interfaceOnly=true у меня, к сожалению, не работает (
MZ
Никто не пробовал использовать следующие плагины для генерации кода моделей и контроллеров для kotlin:
swagger-codegen-maven-plugin или openapi-generator-maven-plugin?
У меня есть проблема с генерацией кода контролеров.
Я хочу, чтобы создавался интерфейс без реализации, а получается класс с реализацией(
swagger-codegen-maven-plugin или openapi-generator-maven-plugin?
У меня есть проблема с генерацией кода контролеров.
Я хочу, чтобы создавался интерфейс без реализации, а получается класс с реализацией(
мы используем вовсю. я бы рекомендовал генерить java. там хоть и есть баги, но всё-таки меньше. если интересен именно котлин, попробуй https://github.com/OpenAPITools/openapi-generator
это сильно переосмысленный форк swagger-codegen, который будет поддерживать 3.0. с ним засада в том, что он по сути альфа версия. багов настолько много, что никакие workaround в нашем случае не помогли.
теперь про interfaceOnly. лучше используй delegatePattern. это позволит имплементить интерфейс делегата и не парится на тему всяких REST-аннотаций. если хочешь, могу кинуть наш конфиг
это сильно переосмысленный форк swagger-codegen, который будет поддерживать 3.0. с ним засада в том, что он по сути альфа версия. багов настолько много, что никакие workaround в нашем случае не помогли.
теперь про interfaceOnly. лучше используй delegatePattern. это позволит имплементить интерфейс делегата и не парится на тему всяких REST-аннотаций. если хочешь, могу кинуть наш конфиг
MZ
Используете ли для описания entity data class?
Если да, то переопределяете hash code/equals или нет?
Если да, то переопределяете hash code/equals или нет?
я правильно понимаю, что ты хочешь в REST использовать свои data классы напрямую? такое возможно, но обычно так не делают. мы используем такое только в особых случаях, например, если хотим явно переиспользовать enum или для правильного наследования. но если припёрло, то есть такая штука как typeMapping в конфиге плагина. можно отмапить сваггеровскую модель на свои классы и тогда сваггеровская модель не будет использоваться.
MZ
* Я хочу, чтобы создавался интерфейс без реализации, а получается класс с реализацией(
скорее всего, ты всё-таки что-то не так настраиваешь. interfaceOnly точно работает, просто он довольно бесполезен, если говорить про spring boot
скорее всего, ты всё-таки что-то не так настраиваешь. interfaceOnly точно работает, просто он довольно бесполезен, если говорить про spring boot
MV
Maxim Zinchenko
мы используем вовсю. я бы рекомендовал генерить java. там хоть и есть баги, но всё-таки меньше. если интересен именно котлин, попробуй https://github.com/OpenAPITools/openapi-generator
это сильно переосмысленный форк swagger-codegen, который будет поддерживать 3.0. с ним засада в том, что он по сути альфа версия. багов настолько много, что никакие workaround в нашем случае не помогли.
теперь про interfaceOnly. лучше используй delegatePattern. это позволит имплементить интерфейс делегата и не парится на тему всяких REST-аннотаций. если хочешь, могу кинуть наш конфиг
это сильно переосмысленный форк swagger-codegen, который будет поддерживать 3.0. с ним засада в том, что он по сути альфа версия. багов настолько много, что никакие workaround в нашем случае не помогли.
теперь про interfaceOnly. лучше используй delegatePattern. это позволит имплементить интерфейс делегата и не парится на тему всяких REST-аннотаций. если хочешь, могу кинуть наш конфиг
Спасибо за ответ!
Да, интересен именно Kotlin.
java с interfaceOnly, у меня, работает.
Насчёт REST-аннотаций согласен, что не удобно, но альтернативный подход мне не понятен.
Можешь привести пример по-подробнее?
Да, интересен именно Kotlin.
java с interfaceOnly, у меня, работает.
Насчёт REST-аннотаций согласен, что не удобно, но альтернативный подход мне не понятен.
Можешь привести пример по-подробнее?
MV
Maxim Zinchenko
я правильно понимаю, что ты хочешь в REST использовать свои data классы напрямую? такое возможно, но обычно так не делают. мы используем такое только в особых случаях, например, если хотим явно переиспользовать enum или для правильного наследования. но если припёрло, то есть такая штука как typeMapping в конфиге плагина. можно отмапить сваггеровскую модель на свои классы и тогда сваггеровская модель не будет использоваться.
Не очень понял вопроса (
Можешь пояснить поподробнее.
Вопрос про data class для entity задан в отрыве от swagger/openapi модели.
Можешь пояснить поподробнее.
Вопрос про data class для entity задан в отрыве от swagger/openapi модели.
RM
Всем привет. Я так понимаю это не первый проект. Может @vlasovmaksim вы напишите как преднастроить ide и какие зависимости подтянуть. Чтобы больше времени осталось на интересные фишки и т.д.
RM
Ну и тогда типа проблема интернета решиться)
В
+1
MV
Всем привет. Я так понимаю это не первый проект. Может @vlasovmaksim вы напишите как преднастроить ide и какие зависимости подтянуть. Чтобы больше времени осталось на интересные фишки и т.д.
Можете пояснить что именно хотите настроить?
В
я так понял человек больше о зависимостях и тп. чтобы этого не делать там, не выкачивать спринг и тп
MZ
Спасибо за ответ!
Да, интересен именно Kotlin.
java с interfaceOnly, у меня, работает.
Насчёт REST-аннотаций согласен, что не удобно, но альтернативный подход мне не понятен.
Можешь привести пример по-подробнее?
Да, интересен именно Kotlin.
java с interfaceOnly, у меня, работает.
Насчёт REST-аннотаций согласен, что не удобно, но альтернативный подход мне не понятен.
Можешь привести пример по-подробнее?
на самом деле не особо понятно, зачем генерить именно котлин, если нужны интерфейсы. вроде как разница копеечная. delegatePattern создаёт контроллеры и создаёт интерфейсы, которые нужно заимплеменить в контексте spring. то есть, это будут обычные POJO-интерфейсы. проще попробовать. собери с delegatePattern=true и увидишь
MZ
Не очень понял вопроса (
Можешь пояснить поподробнее.
Вопрос про data class для entity задан в отрыве от swagger/openapi модели.
Можешь пояснить поподробнее.
Вопрос про data class для entity задан в отрыве от swagger/openapi модели.
а, ок. я думал речь про использование в сваггере. data class для сущностей это немного странно, так как он не для этого создавался
Ⓢ
Народ, может нам устраивать неформальные митапы (без подготовленных докладов), чтобы можно было поговорить очно на интересующие темы типа вот проблемы выше?
Ⓢ
Народ, 15 ноября будет митап в МТС. Там строго-дичайшая пропускная система (хуже чем в банках). Кто не написал своё отчество при регистрации - сообщите мне, пожалуйста. Также сообщите, если вы не гражданин РФ.
MV
Maxim Zinchenko
на самом деле не особо понятно, зачем генерить именно котлин, если нужны интерфейсы. вроде как разница копеечная. delegatePattern создаёт контроллеры и создаёт интерфейсы, которые нужно заимплеменить в контексте spring. то есть, это будут обычные POJO-интерфейсы. проще попробовать. собери с delegatePattern=true и увидишь
Ок, попробую, спасибо!
Я хотел чисто на котлин, чтобы в maven использовать один компилятор, вместо двух.
Я хотел чисто на котлин, чтобы в maven использовать один компилятор, вместо двух.
MV
Maxim Zinchenko
а, ок. я думал речь про использование в сваггере. data class для сущностей это немного странно, так как он не для этого создавался
Согласен, но в примерах встречается, поэтому и возник вопрос.
MV
Ну и тогда типа проблема интернета решиться)
Проблема заключается в интеграции swagger/openapi в проект?
MZ
Ок, попробую, спасибо!
Я хотел чисто на котлин, чтобы в maven использовать один компилятор, вместо двух.
Я хотел чисто на котлин, чтобы в maven использовать один компилятор, вместо двух.
ты генеренные классы мешаешь с остальным кодом? мне просто такое даже в голову не пришло