Попытка включить swagger-codegen с градл котлиндсл - PullRequest
0 голосов
/ 17 января 2019

Я пытаюсь заставить swagger code-gen работать в проекте, построенном с помощью gradle (kotlin).

Вот мой пример: https://github.com/int128/gradle-swagger-generator-plugin, который сделан в отличной версии Gradle.

build.gradle.kts является следующим:

repositories {
    jcenter()
}

plugins {
    java
    id("org.springframework.boot") version "2.1.2.RELEASE"
    id("io.spring.dependency-management") version "1.0.6.RELEASE"
    id("org.hidetake.swagger.generator") version "2.16.0"
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation ("io.swagger:swagger-annotations:1.5.21")
    swaggerCodeGen("io.swagger:swagger-codegen-cli:2.3.1")

    // Use JUnit test framework
    testImplementation ("junit:junit:4.12")
}

swaggerSources {
    petstore {
        inputFile = file('petstore.yaml')
        code {
            language = 'spring'
        }
    }
}

Но IntelliJ не любит строки, говорящие о чванстве enter image description here

Я новичок в учебе, поэтому я не понимаю, что я должен делать. Должен ли swaggerCodeGen быть функцией? Куда эта функция должна быть импортирована? Где swaggerSources предполагается импортировать?

1 Ответ

0 голосов
/ 18 января 2019
import org.hidetake.gradle.swagger.generator.GenerateSwaggerCode

// plugins, repositories are same, but note import above ^^^

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation ("io.swagger:swagger-annotations:1.5.21")
    "swaggerCodegen"("io.swagger:swagger-codegen-cli:2.3.1") // 1

    // Use JUnit test framework
    testImplementation ("junit:junit:4.12")
}

swaggerSources {
    create("petstore").apply { // 2
        setInputFile(file("petstore.yaml")) // 3
        code(closureOf<GenerateSwaggerCode> { // 4
            language = "spring"
        })
    }
}

1 - динамически разрешенная конфигурация в Kotlin выглядит следующим образом (динамически из Groovy, поэтому использовать ее во время компиляции проблематично, оператор вызова расширения для String - наш спаситель);

2 -swaggerSources возвращает вас NamedDomainObjectContainer<SwaggerSource>, поэтому для добавления нового контейнера мы вызываем create с его именем в качестве параметра;

3 - Kotlin не так гибок, как Groovy, поэтому вызывает setter вместо поля установки;

4 - Закрытие Groovy далеко от функционального интерфейса, поэтому мы указываем универсальный тип, как в источниках плагина Closure не параметризован.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...