bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: when dependencies in common to more than one project appear on the classpath
Date Mon, 11 Jun 2012 22:25:19 GMT
On Mon, Jun 11, 2012 at 2:21 PM, Andrew Purtell <apurtell@apache.org> wrote:

> On Mon, Jun 11, 2012 at 10:13 AM, Alejandro Abdelnur <tucu@cloudera.com>
> wrote:
> > On Mon, Jun 11, 2012 at 10:10 AM, Andrew Purtell <apurtell@apache.org
> >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.



If a project dependent on Hadoop uses a non-compat version of Guava (as per
your example), you are just playing russian roulette with your classpath.
IMO, the different projects have to harmonize their component versions,
specially because none of them uses implementation-dependencies isolation
(ie by classloader means). It seem to me a much easier goal to harmonize
than achieve implementation-dependencies isolation. It shouldn't be that
difficult, all the projects are cross-pollinated with developers working in
multiple of them, but this is just my take.

thx

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)
>



-- 
Alejandro

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message