Swagger-codegen: [JAVA] Definitions that are only a type generate references to them instead of the type

[christarczon]

Description

Definitions that are simply a type aren't generated correctly in Maven and CLI generators. Works as expected when generated at editor.swagger.io. I'm trying to generate a Spring Boot client (not available in online editor) but it happens for Java too.

Swagger-codegen version

2.2.3, 2.3.0-SNAPSHOT

Swagger declaration file content or url

swagger: '2.0'
info:
  title: Test
  version: '1'
paths:
  '/list':
    get:
      responses:
        '200':
          description: ''
          schema:
            $ref: '#/definitions/MyList'
definitions:
  MyList:
    type: array
    items:
      $ref: '#/definitions/ListItem'
  ListItem:
    type: string

Command line used for generation

java -jar ./modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -l java -i test.yaml -o test-gen

Steps to reproduce

Generate the above yaml using CLI or Maven. The generated code imports and refers to a model that isn't generated.

Expected:
public class MyList extends ArrayList<String> {

Actual:
public class MyList extends ArrayList<ListItem> {

Related issues/PRs

Suggest a fix/enhancement

I don't understand why this is different from the online editor. Besides the reference to the ListItem class that isn't generated, the files are identical.

[wing328]

@christarczon can you please give it another try with the latest master? I seem to recall a fix merged into master recently.

[christarczon]

@wing328 Just pulled and rebuilt, same thing.

[bbdouglas]

I believe this is the same issue as #5382, which was (at least partially) addressed. I was able to reproduce this issue with the latest master, so the previous fix obviously didn't catch all the cases. I will take a look and see what more needs to be done to cover this case as well.

[bbdouglas]

@christarczon As a short-term workaround, you can reverse the order of the definitions of ListItem and MyList. The issue is that MyList refers to a definition that wasn't defined lexically above it. The spec you wrote is correct, we just don't support that ordering yet for these kinds of "type only" definitions. A more comprehensive fix should be available soon.

[bbdouglas]

I verified that with the latest master this issue has been fixed. I believe this issue can be closed.

Here is the definition of the MyList class now, generated with the spec given in the issue description:

public class MyList extends ArrayList<String> {

[ellavas]

I verified also, the definition is using an arrayList of String. But with this implementation, the validation does not work.
There is no validation of minLength, maxLength, nor uniqueItems.

Is there any workaround ?