swagger-api / swagger-codegen

swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.
http://swagger.io
Apache License 2.0
16.9k stars 6.03k forks source link

[JAVA] Generate Model Type org.joda.time.* For Variables #6404

Open tobwiens opened 7 years ago

tobwiens commented 7 years ago
Description

I am getting following code generated inside the model: Here the property example:

@JsonProperty("commit_time")
  private org.joda.time.* commitTime = null;

Another example:

public CatalogObjectMetadata commitTime(org.joda.time.* commitTime) {
    this.commitTime = commitTime;
    return this;
  }
Swagger-codegen version

I used current master and v2.2.3 tag to test the code generation.

Swagger declaration file content or url

Please find the gist here: https://gist.github.com/anonymous/95b166a38734af9accd944d8b81b0c2f

Command line used for generation
Steps to reproduce

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -l java --library resteasy -Djava8=true -DgroupId=group.id.name -DartifactId=swagger-client

Related issues/PRs

I found a few issue searching for org.joda.time.* which address similar problems, but always as imports not as the type of a variable.

[EDIT]: Works with the online generator. Maybe related to this?: https://github.com/swagger-api/swagger-codegen/issues/6379

Suggest a fix/enhancement

Maybe I am just using the generator wrong. But using org.joda.time.* as a type looks a bit fishy.

Thank you.

Cheers, Tobias

wing328 commented 7 years ago

@tobwiens what about using a different Java datetime lib instead?

    dateLibrary
        Option. Date library to use
            joda - Joda (for legacy app only)
            legacy - Legacy java.util.Date (if you really have a good reason not to use threetenbp
            java8-localdatetime - Java 8 using LocalDateTime (for legacy app only)
            java8 - Java 8 native JSR310 (preferred for jdk 1.8+) - note: this also sets "java8" to true
            threetenbp - Backport of JSR310 (preferred for jdk < 1.8)

Ref: java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar config-help -l java

tobwiens commented 7 years ago

@wing328 I tried to use it with -DdateLibrary=java8, but the same error occurs.

I am surprised that it works with the online generator. I guess there is a specific configuration which works, but I didn't experiment enough to find the correct one.

wing328 commented 7 years ago

cc @cbornet @ePaul @bbdouglas @JFCote @sreeshas @jfiala @lukoyanov

bbdouglas commented 7 years ago

It looks like the problem is that you have a model named LocalDateTime, which conflicts with the same-named time class in Joda (Java 7) and the built-in Java 8 time library. One quick workaround is to rename it to something else, like LocalDateAndTime. Also keep in mind that there is a built-in dateTime data type intrinsic to Swagger, which will be turned into Joda or Java 8 time classes in the Java world.

For a more general fix, I'll need to poke around and see if there is a way for the code generator to detect these kinds of duplicates and do the right thing.

jontro commented 5 years ago

I am experiencing the same problem with the following swagger definition: https://purchase.izettle.com/swagger.json


"LocalTime" : {
  "type" : "object",
   ...
}

Which is then used later on

"localTime" : {
   "$ref" : "#/definitions/LocalTime"
},

Like that.

frantuma commented 5 years ago

Until this gets enhanced (WIP), current options include:

  1. adding to typeMappings options (as cli and maven plugin options or programmatically) the key/value : "LocalTime" -> "LocalTime" This will cause the model to be mapped to joda.time.LocalTime

  2. adding importMappings options the key/value : "LocalTime" -> "org.joda.time.LocalTime" This will also cause the model to be mapped to joda.time.LocalTime

  3. providing a non codegen-generated java class name for LocalTime, adding it to typeMappings or importMappings

  4. as mentioned by @bbdouglas above, renaming the naming conflicting fields (LocalTime) to something else..

  5. .. or using dateTime object type.