Name collision with same class name in different packages

[Raimund Klein]

          @Chessray I'm experiencing a similar name collision. When defining mappers for classes with the same name but different packages, the generated name in the ConversionServiceAdapter is the same:

@Mapper(config = SharedConfig.class)
public interface MyMapper extends Converter<Foo, com.contoso.Bar> {
    com.contoso.Bar convert(Foo source);
}

@Mapper(config = SharedConfig.class)
public interface MyMapper extends Converter<Foo, com.fabrikam.Bar> {
    com.fabrikam.Bar convert(Foo source);
}

// With classes
class Foo {
}

package com.contoso;
class Bar {
}

package com.fabrikam;
class Bar {
}

Is there a simple way around this, or does that require changes to the name generator as well?

Originally posted by @pw-lehre in #86 (comment)

[Raimund Klein]

With the project as it stands, you've got two choices:

1. The most obvious answer is to change the name of one of the Bar classes so it will be unique.
2. A second option would be to spread the Mappers across different packages and have several mapping configurations. The downside is that you'd have to configure the ConversionService manually.

I specifically chose to make the generator not package-aware as I consider this kind of project layout bad practice. But that's just my opinion.

I can imagine adding an annotation on class level that will alter the generated method name to include the package.

[pw-lehre]

I specifically chose to make the generator not package-aware as I consider this kind of project layout bad practice.

Understandable. though in some cases, the classes are from external libraries that version by using a different package name like com.v1.Bar and com.v2.Bar.

In the meantime, I did find another workaround: Using a differently named subclass can replace the parent class in most cases. In the example, that would mean defining an additional class:

class FabrikamBar extends com.fabrikam.Bar {
}

// define mapper for the new class
@Mapper(config = SharedConfig.class)
public interface FabrikamBarMapper extends Converter<Foo, FabrikamBar> {
    FabrikamBar convert(Foo source);
}

I support the idea of overriding the method name, since there are cases where the workaround cannot work (e.g. final classes).