You are right that jar hell and dll hell are not that easy to deal with.
OSGi is supposed to be a way to reduce this problem but IMHUO brings it own problems.
Most reputable projects are pretty careful about compatibility since it is really tough on developers if new versions break existing code. Developers will just refuse to use the library if updates repeatedly break their code.
Breaking your application into smaller independent services may give you a way to reduce the number of conflicts related to these different transitive dependencies but that may not be as easy as testing your app with the updated versions or doing some research with the teams that are building with the old libraries to see if they will upgrade and run their acceptance tests within a time frame that meets your project's timeline requirements.
If the project is open source, you may be able to run the acceptance tests for the dependencies that use old libraries after you change their build to use later versions. That would give you a higher level of confidence and perhaps be a bit of a pay-back to the team that is giving you a helpful library, if you give them the feedback.
Ron On 05/01/2015 4:03 PM, Kevin Burton 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. And it’s not necessarily anyone’s fault. Library A will use library B which depend on library C version 1.1 but then library D will use library C which depends on 1.2… I *mostly* end up with NoClassDefFoundException. But I’m worried about other smaller bugs. For example, if my library wasn’t tested with a later version of a library it isn’t necessarily as reliable out of the box since it wasn’t tested with that config. Has anyone done any work with only allowing a library to use the version of a class it requested? If you release your library fully tested on version 1.1.1 of some library, and someone accidentally starts using 1.1.2 becuase of dependency hell, then we're going to break the build and introduce bugs. 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? For example, it’s possible that libraries could step on each other by creating duplicate threads with the same names, or messing up system properties.
-- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
