Re: when dependencies in common to more than one project appear on the classpath

[Konstantin Boudnik <co...@apache.org>]

In this case the integration project might have to take a bold step and deal
with transitive dependencies explicitly by excluding them and validating new
dependencies tree through the integration testing.

Sure, this puts an extreme burned on the integration project, but there's a
hope to eventually push this function down the the component projects.

Cos

On Mon, Jun 11, 2012 at 03:34PM, Andrew Purtell wrote:
> On Mon, Jun 11, 2012 at 3:25 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> > 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.
> 
> True but the choices and priorities represented by a BOM may not be
> aligned with those of some component project. For example, some are
> making a greater emphasis on testing with an adapting to Hadoop 2 than
> others.
> 
> > 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.
> 
> Sure maybe it will all work out.
> 
> Best regards,
> 
> ═ ═- Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)