Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Mark Derricutt
On 6 Jan 2015, at 12:29, Kevin Burton wrote: I agree. in this case the issue is testing. I need to embed cassandra so I can test it but it’s conflicting with spark. As a total side issue - have you considered using Docker?

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Ron Wheeler
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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Curtis Rueden
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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Kevin Burton
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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Ron Wheeler
On 05/01/2015 6:29 PM, Kevin Burton wrote: 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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Barrie Treloar
On 6 January 2015 at 14:50, Ron Wheeler rwhee...@artifact-software.com wrote: On 05/01/2015 6:29 PM, Kevin Burton wrote: 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

[ANN] Apache Maven Plugin Tools (with Maven Plugin Plugin) 3.4 Released

2015-01-05 Thread Hervé Boutemy
The Apache Maven team is pleased to announce the release of the Apache Maven Plugin Tools, version 3.4 The Maven Plugin Tools contains the necessary tools to generate rebarbative content like descriptor, help and documentation. http://maven.apache.org/plugin-tools/

Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Kevin Burton
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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

2015-01-05 Thread Steven Schlansker
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