swagger-codegen-maven-plugin: generateApis not always honored

[davidcarltonsumo]

Description

I have a multi-module project that uses swagger-codegen-maven-plugin to generate Java stubs. In one of the modules (module A), we don't have generateApis set (which should mean that it is treated as true); for the other (module B), we have it set to false.

Usually, this works, but occasionally we don't get the API classes generated (just the model classes) in module A or else we do get the API classes generated in module B.

If it matters, we are using multithreaded builds.

Swagger-codegen version

2.2.3, 2.3.1.

Swagger declaration file content or url

Proprietary code, I haven't generated an isolated test case yet.

Here's a gist with the swagger configuration in the two poms:

https://gist.github.com/davidcarltonsumo/a941f184abaa017928fa3f298645cb9f

Command line used for generation

Steps to reproduce

I don't have a test case that reproduces it at all reliably.

Related issues/PRs

Issue #6260 might be relevant.

Suggest a fix/enhancement

Reading through the code, my only current hypothesis is that the use of system properties ("api" in this case) to pass configuration information might be relevant - if both modules are executing within the same JVM, then perhaps the value of the property is bleeding over from one execution to the other? I don't understand the swagger-codegen code well enough to understand why system properties are being used here instead of having CodeGenMojo pass the configuration to DefaultGenerator via some other method (e.g. a constructor argument).

[HugoMario]

it would be really helpful to have a way to reproduce this, let me know if you find a way to get the issue and i'll help you with fix.

[davidcarltonsumo]

I unfortunately still don't have an isolated test case. It's currently happening on a multi-module maven project with something like 300 modules inside of it, and it only happens somewhere between 1% and 5% of the time, so while I'm confident that there is a bug, reproducing it is not so easy.

And I also now have good evidence that my theory is correct that it's triggered by pom parameters that CodeGenMojo passes to DefaultGenerator via system properties: I've modified the second pom to leave generateApis, generateSupportingFiles, generateModuleDocumentation, and generateModels with their default values (as the first pom had already done), and the problem no longer occurs. (Those are the pom properties that I was changing that are passed via system properties; other pom properties are passed via a different mechanism, and setting, e.g., modelPackage and apiPackage to different values in the different poms is totally fine.)

https://gist.github.com/davidcarltonsumo/8dc580a25dda77c2e56136fb14c5eb64 shows the workaround that I'm using - it shows the modified version of pom B from my earlier gist. Of course, I don't actually want to generate the api / invoker stuff in pom B; the way the workaround handles that is by leaving generateApis and generateSupportingFiles at their default value of true, but then using an ignoreFileOverride that tells swagger-codegen to not actually generate any of the files that would be generated by those two targets.

My apologies for not having a reproducible test case, but hopefully this narrowing down of the cause will be helpful in fixing it, or alternatively hopefully other people who run into the bug can use the same workaround that I'm using.

[davidcarltonsumo]

also, to help other people who run into the problem find this: one of the error cases (API classes being generated inappropriately) leads to symptoms that look like this:

03:20:44 [INFO] -------------------------------------------------------------
03:20:44 [ERROR] COMPILATION ERROR : 
03:20:44 [INFO] -------------------------------------------------------------
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[16] error: package com.squareup.okhttp does not exist
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[17,40] error: package com.squareup.okhttp.internal.http does not exist
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[18,34] error: package com.squareup.okhttp.logging does not exist
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[19,57] error: package com.squareup.okhttp.logging.HttpLoggingInterceptor does not exist
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[20,11] error: package okio does not exist
03:20:44 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/oas-api/target/generated-sources/src/main/java/com/sumologic/oas/api/generated/audit/invoker/ApiClient.java:[21,11] error: package okio does not exist

and the other error case (API files not being generated even though they should be) looks like this:

05:26:31 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/external/src/main/scala/com/sumologic/external/content/ContentManagementApiDelegateImpl.scala:3: error: object ContentManagementApiDelegate is not a member of package com.sumologic.api.generated
05:26:31 [ERROR] import com.sumologic.api.generated.{ContentManagementApiDelegate, model => swagger}
05:26:31 [ERROR]        ^
05:26:33 [ERROR] /mnt/ubuntu/workspace/Master-PR-Linearbuild-Complete/external/src/main/scala/com/sumologic/external/content/ContentManagementApiDelegateImpl.scala:18: error: not found: type ContentManagementApiDelegate
05:26:33 [ERROR]   extends ContentManagementApiDelegate
05:26:33 [ERROR]           ^

[stahloss]

it would be really helpful to have a way to reproduce this, let me know if you find a way to get the issue and i'll help you with fix.

I just stumbled on this after having a build running in parallel for weeks. Some small change in the reactor seems to trigger the issue. Quite hard to reproduce.