Some openApi plugin settings are ignored since 1.7.0

[nbam-e]

Version Information:

• Springdoc-openapi-gradle-plugin: 1.7.0
• springdoc: 1.7.0
• spring-boot: 2.7.14
• Gradle: 8.2.1 (using groovy)
• OS: linux

Certain properties (e.g. apiDocsUrl, outputDir, outputFileName) within the openApi {} block in the gradle file appear to have no effect since upgrading to 1.7.0 (with 1.6.0 everything works normally).

I noticed it because generateOpenApiDocs always tried to retrieve the openapi file from ' http://localhost:8080/v3/api-docs', regardless of the apiDocsUrl (which fails in our case).

e.g. using the example config from the readme, the generateOpenApiDocs task still tries do download the openapi spec from http://localhost:8080/v3/api-docs instead of https://localhost:9000/api/docs:

plugins {
	id 'java'
	id 'org.springframework.boot' version '2.7.14'
	id 'org.springdoc.openapi-gradle-plugin' version '1.7.0'
}
...
openApi {
	apiDocsUrl.set("https://localhost:9000/api/docs")
	outputDir.set(file("$buildDir/docs"))
	outputFileName.set("swagger.json")
	waitTimeInSeconds.set(10)
	groupedApiMappings.set(["https://localhost:8080/v3/api-docs/groupA": "swagger-groupA.json",
		"https://localhost:8080/v3/api-docs/groupB": "swagger-groupB.json"])
	customBootRun {
		args.set([
			"--spring.profiles.active=special"
		])
	}
}

Interestingly, the property customBootRun still works, so this only seems to affect certain settings.

[bnasslahsen]

Interestingly not reproducible.

Make sure you Provide a Minimal, Reproducible Example - with HelloController that reproduces the problem.

[Exotrom]

@bnasslahsen Please see https://github.com/Exotrom/springdoc-openapi-gradle-plugin/tree/v1.7.0-issue-example for an example to reproduce the issue.
Just check out the branch and run ./gradlew :generateOpenApiDocs. Setting the plugin version to 1.6.0 works.

@nbam-e
My guess is that you also reference something like tasks.withType<OpenApiGeneratorTask> in your gradle file before the openApi block.
Try to move the openApi block up in your gradle file:

import org.springdoc.openapi.gradle.plugin.OpenApiGeneratorTask

plugins {
	[...]
	id("org.springdoc.openapi-gradle-plugin") version "1.7.0"
}
[...]
// this block should be before any of the OpenApiGeneratorTask is referenced
openApi {
	[...]
}
[...]
tasks.withType<OpenApiGeneratorTask> {
	[...]
}
[...]

[bnasslahsen]

@Exotrom,

You should remove the block tasks.withType<OpenApiGeneratorTask> as it is custom settings and not officially supported or tested and try without.

Declaring the openApi block before any of the tasks.withType<OpenApiGeneratorTask> is referenced is also another workaround.

[caspianb]

Not sure if I should post here or open a new issue -- but I am seeing the same error without using tasks.withType<OpenApiGeneratorTask>. I am uncertain if you guys would consider this a bug or not.

If nothing else, this information might at least help others to "workaround" the issue:

It took awhile to track down (we use multiple apply from: "$...\X.gradle" files to help modularize our builds) -- but after playing in a demo application I figured out precisely what caused the issue. If I have a very simple demo project that simply uses spring-web and the openapi-gradle-plugin and I have this in my build.gradle file, it ignores my custom apiDocsUrl property (generateOpenApiDocs tries to connect to 8080 and fails).

// This has been truncated from a spotbugs configuration adapted from this comment:
// See https://github.com/spotbugs/spotbugs-gradle-plugin/issues/32#issuecomment-650213383
tasks.matching { false }.forEach {
}

openApi {
    customBootRun { args.set(["--server.port=15508"]) }
    apiDocsUrl.set("http://localhost:15508/v3/api-docs.yaml")
    waitTimeInSeconds.set(60)
    outputDir.set(file("$rootDir/api"))
}

By simply swapping the tasks.matching block after the openApi block it succeeds in 1.7.0. In my project's case, I can simply swap the apply from orderings to ensure the openapi configuration is loaded first (though not certain if that will always be desirable).

This did only start occurring in 1.7.0 -- 1.6.0 worked without any concerns.

Attached my sample project:
demo.zip

[nbam-e]

@bnasslahsen
I have finally managed to isolate the cause in our case.
It is similar to the issue of @caspianb.

We have a multi-project gradle build and the openapi gradle plugin is only used within a single one of the subprojects.
The openApi plugin configuration breaks if you have something like this in the build.gradle file of the root project:

subprojects.each { p ->
	p.tasks.whenTaskAdded { task -> ... }
}

Attached an example project based on the demo application from your automated tests for reproduction (run via cd root && ./gradlew example:generateOpenApiDocs):
issue-117-reproduction.zip

[cgrabmann]

I just stumbled upon the same issue.

In my opinion it is because the task-property conventions are eagerly initialized with the value of the extension by calling getOrElse on the extension property.

See here:

springdoc-openapi-gradle-plugin/src/main/kotlin/org/springdoc/openapi/gradle/plugin/OpenApiGeneratorTask.kt

Line 57 in fff1285

apiDocsUrl.convention(extension.apiDocsUrl.getOrElse(DEFAULT_API_DOCS_URL))

I'm currently preparing a PR to fix that.

[grahampacker]

When will this issue be resolved as it seems to have been an issue for a couple of months now?