title: Resolving bean conflicts in third-party packages
body: <p>I have an application, let's call it MyApp. An example of the <code>build.gradle</code> looks like this:</p>
  
  <pre><code>compile group: 'com.example', name: 'library'
  compile .. spring-heatoas ..
  </code></pre>
  
  <p>Now, the way this <code>library</code> works is that it expects the host to give it a bean of type <code>ObjectMapper</code>. It by itself does not define an <code>ObjectMapper</code> as the configuration of the same is completely open to the host library. So basically, in the host <code>MyApp</code> I have this config:</p>
  
  <pre><code>@Configuration
  public class SpringConfig {
      @Bean
      public ObjectMapper objectMapper() { ... }
  }
  </code></pre>
  
  <p>Everything is fine and working, till I had the <code>spring-hateos</code> dependency. <code>spring-hateos</code> defines it's own <code>ObjectMapper</code> which goes by the name <code>_hal_objectMapper</code>. So, after adding it, I get a conflict between the two beans. I tried:</p>
  
  <pre><code>@Bean
  @Order(Ordered.HIGHEST_PRECEDENCE)
  public ObjectMapper objectMapper() { ... }
  </code></pre>
  
  <p>Not only does this not work, but even if it did, I guess it has the potential to break functionality as the host application can no longer configure the <code>ObjectMapper</code>. A straightforward solution obviously is to make the <code>library</code> accept a named-bean and then declare it in my host application with a <code>@Qualifier</code> annotation. But getting the library to change (and there are a couple of libraries like that) company-wide is going to be a major pain. While we are considering that solution, is there a way to solve this?</p>