openapi-generator: [BUG] [JAVA] UNKNOWN BASE TYPE when using allOf in request body schema declaration

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What’s the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What’s the actual output vs expected output?

Description

Code generation spills out:

[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] The following schema has undefined (null) baseType. It could be due to form parameter defined in OpenAPI v2 spec with incorrect consumes. A correct 'consumes' for form parameters should be 'application/x-www-form-urlencoded' or 'multipart/form-data'
[WARNING] schema: class ComposedSchema {
    class Schema {
        type: null
		...
		
[WARNING] codegenModel is null. Default to UNKNOWN_BASE_TYPE

Thereafter, we encounter compilation failures:
api/SomewhatApi.java:[7,71] cannot find symbol
  symbol:   class UNKNOWN_BASE_TYPE

openapi-generator version

• 3.3.4
• 4.0.0

Both versions are affected.

OpenAPI declaration file content or url

Gist URL: https://gist.github.com/Emdee89/b3bcab67c46fd6c49d9282a528313990

Command line used for generation

Maven Plugin execution:

<plugin>
        <groupId>org.openapitools</groupId>
        <artifactId>openapi-generator-maven-plugin</artifactId>
        <version>4.0.0</version>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <inputSpec>${project.basedir}/src/main/resources/spec.yaml</inputSpec>
              <output>${project.basedir}</output>
              <generatorName>java</generatorName>
              <configurationFile>${project.basedir}/src/main/resources/api-options.json</configurationFile>
              <generateApiTests>false</generateApiTests>
              <generateModelTests>false</generateModelTests>
              <generateApiDocumentation>true</generateApiDocumentation>
              <generateModelDocumentation>true</generateModelDocumentation>
              <generateSupportingFiles>true</generateSupportingFiles>
              <apiPackage>api</apiPackage>
              <modelPackage>model</modelPackage>
              <invokerPackage>invoker</invokerPackage>
              <removeOperationIdPrefix>true</removeOperationIdPrefix>
              <generateAliasAsModel>true</generateAliasAsModel>
            </configuration>
          </execution>
        </executions>
      </plugin>

api-options.json:

{
  "java8" : true,
  "dateLibrary" : "java8",

  "serializableModel" : true,
  "booleanGetterPrefix" : "is",
  "hideGenerationTimestamp" : false,

  "library" : "resttemplate",
  "sourceFolder" : "/src/main/java"
}

Steps to reproduce

Execute the Maven Plugin with the execution configuration shown above.

Related issues/PRs

Related issues: https://github.com/OpenAPITools/openapi-generator/issues/2030 https://github.com/OpenAPITools/openapi-generator/issues/185

Suggest a fix

The generator appears to lack a concept for creating base types for schemas being used in conjunction with allOf.

In related issues I found the recommendation to use allOf inline. I applied this workaround. See this gist: https://gist.github.com/Emdee89/cd188cb35721b080c101cc10ee757189

####### Workaround

I basically introduced the model named Workaround that serves as a layer in between. I declared the allOf within Workaround instead of within responses of the endpoint. When executing the code generation with this workaround, all warnings/errors from above are gone and the code compiles. However, the generated code looks unexpected.

See Workaround.java:

public class Workaround extends SomewhatIn1 implements Serializable {

Workaround extends SomewhatIn1, but it should also be in a relationship with SomewhatIn2. Consequently, I cannot claim that this workaround solves the problem.