Reference external file (openapi spec) from gradle plugin (openapitools generator) - java

I am attempting to build an application that references an openapi spec that is already published in artifactory. That means I'll be pulling the foo.yaml in as a dependency, but I can't seem to figure out how to actually reference that file by the openapitools generator plugin.
Given that openapi specs can be used to generate both server code and client code, it makes perfect sense that it is published separately and simply pulled in and referenced by implementations.
com.company.bar-1.0.10 contains foo.yaml at the top level of the jar.
I've added the dependency at the top level of the build.gradle.kts file and I've also added it as a part of the plugin task itself.
task generateFooCode(type: org.openapitools.generator.gradle.plugin.tasks.GenerateTask) {
generatorName = "java"
apiPackage = 'com.ehi.gbo.openapiconnect.api.foo'
modelPackage = 'com.ehi.gbo.openapiconnect.model.foo'
invokerPackage = 'com.ehi.gbo.openapiconnect.common.invoker'
inputSpec = "foo.yaml".toString()
outputDir = "$buildDir/generated-sources/foo".toString()
configOptions = [
dateLibrary : "java8",
useTags : true,
interfaceOnly : true,
delegatePattern : false,
useBeanValidation : false,
performBeanValidation: false,
useOptional : false,
serviceImplementation: false,
serviceInterface : false,
java8 : false,
serializableModel : true,
skipDefaultInterface : true,
reactive : false,
]
configurations {
dependencies {
implementation 'com.company.bar:foo-api:1.0.10'
}
}
}
Results I'm getting:
* What went wrong:
Execution failed for task ':generateFooCode'.
There were issues with the specification. The option can be disabled via validateSpec (Maven/Gradle) or --skip-validate-spec (CLI).
| Error count: 1, Warning count: 0
Errors:
-unable to read location foo.yaml

After a lot of googling, I came across a very elegant solution.
configurations {
api
}
dependencies {
api 'somegroup:someArtifact:someVersion'
}
task extractApi(type: Sync) {
dependsOn configurations.api
from { // use of closure defers evaluation until execution time
configurations.api.collect { zipTree(it) }
}
into "$buildDir/api/"
}
Then I could just make the inputSpec reference $buildDir/api/spec.yaml

Related

Gradle: compile and run a single test

I have a separate task to run the test that generates open-api.yml specification for my application. Here is the Gradle configuration below:
task generateOpenApiYml(type: Test) {
group = 'verification'
useJUnitPlatform {
includeTags 'openApi'
}
testLogging {
showExceptions true
showStandardStreams = false
showCauses true
showStackTraces true
exceptionFormat "full"
events("skipped", "failed", "passed")
}
}
So, I have one test with openApi JUnit tag. It works very well, but there is a slight thing I want to approve.
The whole idea of this test is that the result open-api.yml file is used to generate Java client to invoke REST endpoints. This client is used in other tests in the project.
I want to put those generated Java classes to .gitgnore because they are generated anyway and there is no need to index those files. The problem is that the generateOpenApiYml task compiles all the tests in src/test/java directory. Therefore, some of them use generated classes. Which leads to compiling errors.
Is it possible to tune the generateOpenApiYml task to make it compile and run only the single test with openApi JUnit tag? Then I could easily put generated Java classes to .gitignore and don't bother about their temporary absence, because other tests won't be compiled.
I figured out the solution. Firstly, I installed the gradle-testsets-plugin.
Then I configured a separate source set like this:
testSets {
generateOpenApiYml
}
So, generateOpenApiYml is the new Gradle task that looks for sources in src/generatedOpenApiYml/java directory.
Afterwards, we need to tune all tasks of test type to bind them with JUnit 5 platform.
tasks.withType(Test) {
group = 'verification'
useJUnitPlatform()
testLogging {
showExceptions true
showStandardStreams = false
showCauses true
showStackTraces true
exceptionFormat "full"
events("skipped", "failed", "passed")
}
}
generateOpenApiYml.outputs.upToDateWhen { false }
I put the upToDateWhen option for convenience to make sure the generateOpenApiYml task is always run on demand and never cached.
Then I have the open-api-generator.
openApiGenerate {
inputSpec = "$buildDir/classes/java/generateOpenApiYml/open-api.json".toString()
outputDir = "$buildDir/generated/openapi".toString()
apiPackage = "..."
invokerPackage = "..."
modelPackage = "..."
configOptions = [
dateLibrary : "java8",
openApiNullable: "false",
]
generatorName = 'java'
groupId = "..."
globalProperties = [
modelDocs: "false"
]
additionalProperties = [
hideGenerationTimestamp: true
]
}
tasks.named('openApiGenerate') {
dependsOn generateOpenApiYml
}
Finally, I just need to run two commands to build and run tests for my whole project.
./gradlew openApiGenerate
./gradlew build
The first one creates the open-api.yml file and generates Java client according to the provided specification. The second one runs tests and build the project normally. The tests running during the build phase uses classes generated by openApiGenerate task. Therefore, I can put them to .gitignore safely.
Hope this will be helpful.

openapi-generator gradle plugin output directory

I am using the openapi-generator Gradle plugin to generate model files from the open API schema.
With these settings in build.gradle script everything seems ok:
openApiGenerate {
globalProperties = [
apis: "false",
modelDocs: "false",
models: "Pet"
]
generatorName = "java"
generateModelTests = false
inputSpec = "$rootDir/src/main/resources/schema/my_schema.json".toString()
outputDir = "$rootDir".toString()
modelPackage = "org.openapi.example.model"
configOptions = [
dateLibrary: "java8",
serializationLibrary: "jackson",
library: "jersey1"
]
}
And the result classes are generated in the proper package:
The problem is here - I don't need them in my sources, I need them only at compile stage.
I want them to be generated in the build directory, to separate them from other logic.
But when I am changing the output-dir to "$buildDir/generated".toString() this happens:
Is there a way to get rid of the wrong packages "src.main.java"?
You can set the "sourceFolder" option to an empty string.
configOptions = [
sourceFolder: ""
]
This is an option of the generator not of the gradle plugin.
https://openapi-generator.tech/docs/generators/java

How to use Room Database in Android with Bazel?

I have lots of SQLite tables that has now become hard to manage at the app side because of multiple DAO classes. I am using Bazel as my build system but I can't figure out how to use Room DB with Bazel build system.
If you use a Maven artifact resolver like rules_jvm_external, it'll look something like this.
In your WORKSPACE file, add the dependency on the Room compiler:
load("#rules_jvm_external//:specs.bzl", "maven")
maven_install(
name = "maven",
artifacts = [
"androidx.room:room-runtime:2.1.0-alpha04",
"androidx.room:room-compiler:2.1.0-alpha04",
"com.google.guava:guava:28.1-android",
maven.artifact("com.google.auto", "auto-common", "0.10", neverlink = True),
# .. other artifacts
],
repositories = [
"https://maven.google.com",
"https://jcenter.bintray.com",
],
)
In a BUILD file (e.g. <project root>/BUILD), create the java_plugin target to expose the annotation processor for Room:
java_plugin(
name = "androidx_room_room_compiler_plugin",
processor_class = "androidx.room.RoomProcessor",
deps = ["#maven//:androidx_room_room_compiler"],
neverlink = True,
)
java_library(
name = "androidx_room_room_compiler_library",
exports = [
"#maven//:androidx_room_room_compiler",
],
exported_plugins = [
":androidx_room_room_compiler_plugin"
],
)
Finally, in your app's BUILD file, depend on the Room compiler and runtime:
android_library(
name = "lib_prod",
# ...
deps = [
"#maven//:androidx_room_room_runtime",
"//:androidx_room_room_compiler_library",
],
)
I have ported an Android sample app that uses the Room and Lifecycle libraries to build with Bazel here: https://github.com/jin/BasicRxJavaSample-Bazel

Gradle: how can I use dynamic properties on multiple tasks to fail a build?

One of my build tasks pulls information on the current SVN branch. On builds from a tag I want to be more strict and fail the build when e.g., a link checker finds dead links for the online help files. On regular builds from branches or trunk this should not break the build.
I have the following code, where the mentioned Perl script creates a properties file:
task generateSvnInfo(type: Exec) {
outputs.files "generated/svninfo"
executable "perl"
args "..."
}
Properties buildProps = new Properties()
task svninfo() {
inputs.files generateSvnInfo.outputs.files
outputs.upToDateWhen { false }
buildProps.load(new FileInputStream(inputs.files.getSingleFile()))
}
Now my other targets depend on svninfo (and the fact that it populates buildProps).
task checkHelpLinks(type: Exec) {
dependsOn "svninfo"
executable "perl"
args "..."
}
This will always fail if it finds dead help links. As far as I understand it, ignoreExitValue is false by default. To set it to true on non-tag builds, I can add this to the checkHelpLinks task:
ignoreExitValue = true
doLast {
ignoreExitValue = buildProps.FROM_TAG == "false"
}
This works, but I have four or five of these check tasks and would like to not duplicate that code around. So I tried
tasks.grep(~ /^check.+/).each { task ->
task.ignoreExitValue = true
task.doLast {
task.ignoreExitValue = buildProps.FROM_TAG == "false"
}
}
This code does not seem to get executed. I thought that may be because I compare the Task object to a String in grep, but using
tasks.grep(it.name =~ /^check.+/).each { task ->
gets me a build script error ("Could not find property 'it' on root project 'foo'.)
How can I add my tag check to all check tasks?
Is there a better way to load the properties from a file that is created as part of the build process?
Is there a SVN plugin that would do the work for me?

Is it possible to specify multiple main classes using gradle 'application' plugin

I would like to use the Gradle "application" plugin to create startScripts for a second mainClass. Is this possible? Even if the application plugin doesn't have this functionality built in, is it possible to leverage the startScripts task to create a second pair of scripts for a different mainClass?
Add something like this to your root build.gradle:
// Creates scripts for entry points
// Subproject must apply application plugin to be able to call this method.
def createScript(project, mainClass, name) {
project.tasks.create(name: name, type: CreateStartScripts) {
outputDir = new File(project.buildDir, 'scripts')
mainClassName = mainClass
applicationName = name
classpath = project.tasks[JavaPlugin.JAR_TASK_NAME].outputs.files + project.configurations.runtimeClasspath
}
project.tasks[name].dependsOn(project.jar)
project.applicationDistribution.with {
into("bin") {
from(project.tasks[name])
fileMode = 0755
}
}
}
Then call it as follows either from the root or from subprojects:
// The next two lines disable the tasks for the primary main which by default
// generates a script with a name matching the project name.
// You can leave them enabled but if so you'll need to define mainClassName
// And you'll be creating your application scripts two different ways which
// could lead to confusion
startScripts.enabled = false
run.enabled = false
// Call this for each Main class you want to expose with an app script
createScript(project, 'com.foo.MyDriver', 'driver')
I combined parts of both of these answers to arrive at the relatively simple solution:
task otherStartScripts(type: CreateStartScripts) {
description "Creates OS specific scripts to call the 'other' entry point"
classpath = startScripts.classpath
outputDir = startScripts.outputDir
mainClassName = 'some.package.app.Other'
applicationName = 'other'
}
distZip {
baseName = archivesBaseName
classifier = 'app'
//include our extra start script
//this is a bit weird, I'm open to suggestions on how to do this better
into("${baseName}-${version}-${classifier}/bin") {
from otherStartScripts
fileMode = 0755
}
}
startScripts is created when the application plugin is applied.
You can create multiple tasks of type CreateStartScripts and in each task you configure a different mainClassName. for convenience, you can do this in a loop.

Categories