Hi Kevin, I agree with Steven. One way of resolving this sort of problem without OSGi is to use a consistent, meaningful versioning system such as Semantic Versioning (http://semver.org/). Once you have the ability to reason about forwards and backwards compatibility, it is easier to resolve version conflicts in a more reliable (ideally automated) way.
Of course, all the tools you are using do not necessarily abide by such versioning standards. So then conflict resolution becomes more complicated. Steven's suggestion of "managing them upwards to the latest needed" is often good enough... Regards, Curtis On Mon, Jan 5, 2015 at 3:20 PM, Steven Schlansker < stevenschlans...@gmail.com> wrote: > > On Jan 5, 2015, at 1:03 PM, Kevin Burton <bur...@spinn3r.com> wrote: > > > I spent a ton of time tonight in classpath hell. > > > > Basically, Apache Spark, Cassandra, and Cassandra Unit, and Guava, > Jackson > > JSON, and Jetty have an INSANE dependency graph. They're all trampling > on > > each other with broken > > dependencies. This results in a lot of <exclusion> work to get them to > use > > sane bindings. > > > > Has anyone done any work with only allowing a library to use the version > of > > a class it requested? > > > > So what would happen is every dependency would only be sourced from the > > version you require. > > > > This could be done via a hierarchical class loader. Of course this would > > probably end up burning up some memory but probably worth it. > > > > The main issue, is it WORTH it.. would this introduce new bugs? > > You are basically talking about OSGi or some other such module system. > https://en.wikipedia.org/wiki/OSGi > > In my opinion, it is actually easier to resolve the dependency conflicts > among > the modules (usually by managing them upwards to the latest needed by any > dependency) > and tracking this via a plugin [1] > > Having such complicated class loader situations just leads to even more > subtle and confusing bugs IMO. > > [1] https://github.com/ning/maven-dependency-versions-check-plugin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
