hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: very old dependencies
Date Fri, 28 Mar 2014 18:04:05 GMT
On 28 March 2014 17:00, Sandy Ryza <sandy.ryza@cloudera.com> wrote:

> My understanding is that unfortunately we're stuck with these for the rest
> of 2.x, because changing them could break jobs that rely on them.  For jobs
> that want to use newer versions, the recommendation is to use
> mapreduce.user.classpath.first or turn on classpath isolation with
> mapreduce.job.classloader.

If you look at the compatibility statement of hadoop it makes clear there
are no guarantees about dependencies and especially transitive ones.


That is not an accident -any statement of stability would risk painting us
into a corner and never able to update anything. It also allowed us to ship
hadoop 2.2 without doing a rush update of every dependency -that would only
have caused chaos and delays. Protubf -> 2.5 was enough -and that was done
because it was even worse than guava in terms of compatibility policy.

The issue goes beyond MR as YARN apps pick up the core binaries, so are
constrained by what comes in hadoop/lib. hdfs/lib and yarn/lib. most of
which is pretty dated.

and if you have an app like hbase or accumulo, with more current
dependencies, you have to play games excluding all of hadoop's
dependencies. But even that doesn't help with Guava, because it is so
aggressive about retiring classes and methods.

for the sake of our own code and more modern apps, I'm in favour of
gradually rolling out updates that don't break things, force a move to
java7 or require changes to the source.

NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

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