[CHY872]

I can see that. We found that if we added the Spotify Docker Client to our test classpath we couldn't run the application from Eclipse anymore because our Jackson object mapper had the wrong Jersey modules.

This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.

It was a mess.

[i2shar]

Classpath issues such as yours are very common in Java. I suppose that's why building a fat jar is part of the getting started section of the docs.

[einrealist]

Although it is very easy to add dependencies via Maven or Gradle, this does not prevent you from shooting yourself into the foot. You have to manage dependencies, including transitive ones. If the application has too many conflicting dependencies, then use classloader isolation (e.g. OSGi).

It is a littlebit sad, that there are no javac warnings enabled by default that at least check known classes for conflicts in the classpath. An IDE should do that by default, too.

[quicksilver03]

That's 100% Eclipse's fault however, nothing to do with Jersey or Jackson.

[sorokod]

That's dynamic linking for you - you need to take the good with the bad

[StreamBright]

You just pointed out how a feature missing in your tooling can lead to problems. This has nothing to do with Dropwizard though.