Reputation: 35
I want to use the swagger-gradle-plugin from the swagger-core project to resolve my JAX-RS api to a OpenApiDefinition.
Now my problem ist that the plugin uses the library com.fasterxml.jackson.core:jackson-databind
in the version 2.9.10
. My project also uses this library but in the verson 2.10.0
. Now when I run the resolve task of the plugin I get a VerifyError
because a class was changed. I already opened a issue on github but the problem seems to be my configuration.
This is my gradle build file:
plugins {
id "io.swagger.core.v3.swagger-gradle-plugin" version "2.0.10"
}
dependencies {
...
implementation 'io.swagger.core.v3:swagger-annotations:2.0.10'
implementation "com.fasterxml.jackson.core:jackson-databind:2.10.0"
implementation "com.fasterxml.jackson.core:jackson-annotations:2.10.0"
...
}
resolve {
outputFileName = 'lcapi'
outputFormat = 'YAML'
prettyPrint = 'TRUE'
classpath = sourceSets.test.runtimeClasspath
resourcePackages = ['com.example.lc.api']
resourceClasses = ['com.example.lc.api.LcRestController', 'com.example.lc.api.LcStateController']
outputPath = file("${project.projectDir}/src/main/resources")
}
Upvotes: 3
Views: 1677
Reputation: 7598
There are a few ways you can get around it, but I think the simplest one is to create a new configuration that extends from the one you are using, but with a resolution strategy that forces the particular version of Jackson. It could look like this:
plugins {
id "io.swagger.core.v3.swagger-gradle-plugin" version "2.0.10"
}
configurations {
swagger {
extendsFrom runtimeClasspath
resolutionStrategy {
force 'com.fasterxml.jackson.core:jackson-databind:2.9.10'
force 'com.fasterxml.jackson.core:jackson-annotations:2.9.10'
}
}
}
dependencies {
implementation 'io.swagger.core.v3:swagger-annotations:2.0.10'
implementation "com.fasterxml.jackson.core:jackson-databind:2.10.0"
implementation "com.fasterxml.jackson.core:jackson-annotations:2.10.0"
// ...
}
resolve {
classpath = sourceSets.main.output + configurations.swagger
// ...
}
Note that I made it use the normal runtimeClasspath
instead of the testRuntimeClasspath
that you were using, as I expect the other one was just an attempt at making it work (you probably don't want test resources bleeding into the main resources).
Upvotes: 2