Model substitutions fail - ModelModifier loads classes with the default classloader

[delego-wlritchi]

Here's an excerpt from my Gradle config (anonymized):

plugins {
    id 'com.benjaminsproule.swagger' version '1.0.2'
}
swagger {
    apiSource {
        locations = ['com.example.api']
        schemes = ['https']
        basePath = '/api'
        info {
            title = 'Example API'
            version = project.version
            description = 'An example API'
        }
        outputFormats = ['json', 'yaml']
        modelSubstitute = "/swagger-substitutions.txt"
        swaggerDirectory = "$projectDir/build/swagger"
        swaggerFileName = 'swagger'
    }
}

The content of buildSrc/src/main/resources/swagger-substitutions.txt:

java.math.BigDecimal : java.lang.String
com.example.model.Foo : java.lang.String
com.example.model.Bar : com.example.codec.Baz

And here's the task output:

> Task :generateSwaggerDocumentation 
Problem with loading class: com.example.model.Foo. Mapping from: com.example.model.Foo to: java.lang.String will be ignored.
Problem with loading class: com.example.model.Bar. Mapping from: com.example.model.Bar to: com.example.codec.Baz will be ignored.
Problem with loading class: com.example.codec.Baz. Mapping from: com.example.model.Bar to: com.example.codec.Baz will be ignored.

Ultimately, the issue is that the classes are not available on the buildscript classpath, so ModelModifier's Class.forName fails. This issue did not occur in 0.1.9.

One possible solution would be to load classes using the same classloading logic as is used in the ClassFinder. I think that care might need to be taken here since the JavaType instances will have to be the same for map lookups to work - thus, the two probably need to use the same classloader.

Another solution might be for ModelModifier to track classes by fully qualified name rather than by resolving them to JavaType objects. I'm not clear on the internals of this plugin, so I'm not sure if this is in line with the grand design or not.

[gigaSproule]

I think I'll tie this in with issue #56. Although it sounds different, it'll be easier to fix it all together as I'm sure fixing the first will just lead to this issue more.

[michaelruocco]

Does PR #65 fix this as well? It sounds similar to the issue I originally encountered after fixing issue number #56.