On Mon, Jun 11, 2012 at 10:13 AM, Alejandro Abdelnur <[email protected]> wrote: > On Mon, Jun 11, 2012 at 10:10 AM, Andrew Purtell <[email protected]>wrote: >> In the SLF4J case it's not enough just to harmonize the version, there >> can only be one instance of it on the classpath.Even one case like >> this requires the ability to refactor the classpath? > > IMO a solution for this would be: > > 1* harmonize all dep versions > 2* assuming #1, have a classpath constructor script that dedups all JARs in > the classpath given a list of JAR dirs > 3* use the classpath from #2 to run the app
Assuming #1 in all cases is probably not a viable strategy. Guava is an example of how a version change can require nontrivial source changes, and different projects will have different priorities. A number of projects use LimitedPrivate interfaces. Security in general has an evolving API. And that's before the more fun aspects of Hadoop "cooptition" might become involved. Given simple dedup is not enough, the classpath constructor script would need some kind of dependency tracking and manifest? That should be tied in to the capabilities of the OS package manager? Consider from http://duncan.mac-vicar.com/2012/01/26/on-java-maven-jpp-and-rpm/: >>> /usr/share/java/foo1.jar /usr/share/java/foo2.jar /usr/share/java/org.bar/1.0/foo.jar -> /usr/share/java/foo1.jar /usr/share/java/org.bar/2.0/foo.jar -> /usr/share/java/foo2.jar /usr/share/java/org.bar/1.0/foo.pom /usr/share/java/org.bar/2.0/foo.pom /usr/share/java/foo.jar -> /etc/alternatives/foo.jar <<< A path / symlink based layout like this would be supportable with apt, yum, etc. As a newcomer I'm probably rehashing an old discussion and for that I apologize. Just trying to figure out how one might manage an evolving deployment given a 3-5 year timeframe. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
