Hi Kevin, My projects handles it as follows:
1) Death to uber-JARs; use component JARs whenever they exist. If they don't exist, consider forking the project to create them, or at least shading the embedded dependencies. (E.g.: https://github.com/scijava/jython-shaded) 2) Use excludes to avoid bogus transitive dependencies. For example, no one should depend on xml-apis, since those classes come with Java. But lots of projects do. So just exclude xml-apis:xml-apis in your dependencyManagement section for all afflicted projects. Probably also xalan:xalan, maybe xerces, etc. 3) Contact project maintainers upstream to inform them when you find these situations. Many build systems simply do not alert the maintainers that anything like this is happening. So they may just be clueless (though Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know about the joda overlap in this case... but still, may as well ask about it). E.g.: we had one dependency where the project's gradle build system was putting *two copies of each class* into the final JAR artifact! Guess how much maven-enforcer-plugin liked that? :-) 4) Finally, if you have to do it, just add some class excludes to your maven-enforcer-configuration. Especially for cases like joda, chances are the two copies of the classes are identical, so having both on the classpath will work just fine, pragmatically. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton <[email protected]> wrote: > We have a rather complex classpath in our app... sometimes maven computes > the wrong classpath because one package changes classpath order and has a > dependency on an earlier jar. > > To avoid this we usually analyze our classpath between builds and our > builds break if a classpath change isn't approved. > > One of the BIG problems here is when we get overlapping classes. > > Right now this is happening with joda time and joda convert. WE have about > 10 classes that are in both .jars. > > First. It seems irresponsible for project maintainers to release artifacts > like this. If there are shared .classes just publish a new -core artifact. > > Just being pragmatic.. I'm not sure the BEST way to handle this. > > One strategy is to make sure that each lib is the LATEST .. but sometimes > that's not possible. > > How do you guys handle this? > > -- > > We’re hiring if you know of any awesome Java Devops or Linux Operations > Engineers! > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> >
