The failure analysis for a NoSuchMethodError currently assumes that the source of the problem is the method that's being called and not the code that's calling it. Here's an example:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.springframework.data.rest.core.support.UnwrappingRepositoryInvokerFactory.<init>(UnwrappingRepositoryInvokerFactory.java:57)

The following method did not exist:

    org.springframework.plugin.core.PluginRegistry.of(Ljava/util/List;)Lorg/springframework/plugin/core/PluginRegistry;

The method's class, org.springframework.plugin.core.PluginRegistry, is available from the following locations:

    jar:file:/~/.m2/repository/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar!/org/springframework/plugin/core/PluginRegistry.class

It was loaded from the following location:

    file:/~/.m2/repository/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar


Action:

Correct the classpath of your application so that it contains a single, compatible version of org.springframework.plugin.core.PluginRegistry

It could be that the wrong version of PluginRegistry is on the classpath but it could also be the version of UnwrappingRepositoryInvokerFactory that's wrong. We should update the failure analysis to consider this possibility by including information about the location from which the caller was loaded in the description. The action should also be updated to consider the calling side too.