Use generated openapi client as subproject

Help/Discuss
1

Hi,

I’m trying to generate an API Client as a library to consume by my main build. I’m using kotlin and also generating a kotlin api client, but the same would go for java I guess.

I know, that I could just add the src/main/kotlin dir of the generated stuff to my srcDirs, but then I’d have to manually add all the dependencies that the generated API Client needs.

Is there a way, to include the generated stuff as a sub project, even before it is actually generated? I tried the following, but that didn’t work when I didn’t first execute the generate task.

plugins {
	kotlin("jvm") version "2.0.0"
	id("org.openapi.generator") version "7.7.0"
}

repositories {
	mavenCentral()
}

dependencies {
	implementation(":api-client")
}

tasks {
	compileKotlin {
		dependsOn("openApiGenerate")
	}
}

java {
	toolchain {
		languageVersion = JavaLanguageVersion.of(21)
	}
}

kotlin {
	jvmToolchain(21)
}

openApiGenerate {
	generatorName = "kotlin"
	inputSpec = "$rootDir/api/artifactsmmo.yaml"
	outputDir = "$rootDir/api-client"
	//apiPackage = "de.jball.kotlin.artifactsmmo.client.api"
	//modelPackage = "de.jball.kotlin.artifactsmmo.client.model"
	//invokerPackage = "de.jball.kotlin.artifactsmmo.client.invoker"
	packageName = "de.jball.kotlin.artifactsmmo.client"
	configOptions = mapOf(
		"modelDocs" to "false",
		"omitGradleWrapper"	to "true"
	)
}

Any Ideas?

Edit: I found, that remote git repositories via sourceControl in settings.gradle.kts. Is it also possible to utilize that to include the dependency to the content generated by openApiGenerate task?

2

I think the (imho stupid) idea behind how it is, is that you generate and commit the result.

If you execute the task to generate the files, you are already in the execution phase and cannot change any configuration anymore, let alone adding files for a whole project.

I indeed tend to disable all generation except for the source files and then define the generation task as srcDir(...), adding the necessary dependencies myself.

And I use the Java client even from Kotlin, because - unless this changed since I last checked - the Kotlin client is heavily using state in companion object, which is like static state in Java and is pretty bad, especially when using it in something like a Gradle plugin where the static state then pollutes furhter builds.

3

I really don’t like the Idea of checking in generated code. I’d like to be able to update the Api by just changing the api file (with checked in generated code it would be a two step process).

Would it be an idea to have A build-plugin that resolves dependencies based on an OpenAPI Spec? Just like the one that resolves git-dependencies (is that even a plugin?)? Or is there an easier way to achieve a single step OpenApi code generation?

4

I have no idea what you mean with your second paragraph, but I fully agree to the first. That’s why I do it like I described and imho is the cleanest approach.

As long as you generate a Gradle build by runing a Gradle task, you will always have a hard time to then directly use it.