springfox: Duplicate class names in different packages get squashed in ControllerDocumentation - modelMap

@Chinna-SHS The easiest for now is to use the @ApiModel attribute and set different values on the two.

e.g.

package v1;
@ApiModel("V1Model")
class ModelX {}

package v2;
@ApiModel("V2Model")
class ModelX {}

@MaksimOrlov Just tried 3.0.0 and the issue is still not fixed.

Maybe because in my case the difference is not a package name, but an outer class name:

package my.package.dto;

public class User {
  private Location location;

  public static class Location {
    private String name;
  }
}

And:

package my.package.dto;

public class Car {
  private Location location;

  public static class Location {
    private Long id;
    private String address;
  }
}

Only one Location model is present in the generated docs. So, one of User or Car has incorrect model for location property.

I upgraded to 2.9.2 and am still seeing this issue

I have run into this as well. Any updates on progress around this is a fix still targeted for 2.7.0? Is there anything we can do to help out with a fix?

Also, my classes are generated by JAXB and thus cannot be modified with the ApiModel property specified in the workaround. Was this supposed to be fixed in 2.9.0?

@vignesharunachalam I had the same issue lately. Until a clear solution arises, you can always go around the problem by annotating at least one of your model with @ApiModel and use a unique name (e.g. LegacyPet for instance)

Thanks for getting back to me so quickly with this. So I completely agree with you on the two points you have outlined. Based on what you are saying and it completely makes sense is that I would rename my objects that are similar to give them a more distinct name.

For the example you outlined above you could have com.xxxxxx.canonical.Pet and com.xxxxxx.summary.PetSummary or com.xxxxxx.canonical.PetSummary. That way the domain objects are distinct and there is no confusion about what Pet domain object is what.

The above annotation becomes valuable when you supporting multiple versions of a given service (happens all the time because consumers might not want to move to the latest…for whatever reason). Imagine this package structure:

 com.xxxxxx.v1.canonical.Pet
 com.xxxxxx.v2.canonical.Pet

I know ideally your canonical model shouldn’t change but in practice this happens I see these things happen:

1. Business needs/rules change
2. You learn there is a better way to represent your data for your clients
3. Deprecate features that are no longer applicable
4. Lazy consumers don’t have “time” to upgrade

Service versioning is always an interesting topic. Again I really appreciate the help.