Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> documentation on dealing with legacy Hadoop versions


Copy link to this message
-
Re: documentation on dealing with legacy Hadoop versions
the Hadoop policy here is "no guarantees":
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Compatibility.html

that said, nobody rushes to update things, especially on the 2.x branch
-protobuf was traumatic enough that google guava is on hold, leading to
BOOKEEPER 708

Apart from the google artefacts, which pretty aggressively drop features in
a way that shows their single-trunk build and release process, there's less
fear of updating (most) other JARs, and participation in doing so could
benefit Accumulo, especially if the dependencies could be made consistent
between Hadoop 2.4 and accumulo 1.6

https://issues.apache.org/jira/browse/HADOOP-9991

as usual, patches & tests welcome

On 3 January 2014 16:45, Sean Busbey <busbey+[EMAIL PROTECTED]> wrote:

> On Fri, Jan 3, 2014 at 10:26 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
> >
> > Point of reference: HBase-0.96.0 will pull *all* dependencies into
> > $HBASE_HOME/lib. Now, while I don't think I want to re-package all of the
> > Hadoop jars and its dependencies, I don't think it's unreasonable to
> > repackage ones that may be duplicated by the hadoop distribution that we
> > specifically need (thinking specifically of the commons-*).
> >
> >
> Definitely we should not include the Hadoop jars, since it led HBase to
> have to include deployment steps like "remove the packaged Hadoop jars"[1].
>
> I think repackaging any transitive dependencies of Hadoop is a good idea,
> since it makes us more robust to classpath issues. My one concern would be
> that we make sure we pick versions that are not going to cause
> compatibility issues based on wether our or Hadoop's version ends up on the
> classpath first[2]. In the simplest case, that would mean having our
> version match Hadoop's.
>
> -Sean
>
> [1]: http://hbase.apache.org/book.html#replace.hadoop
> [2]: this already happened with Guava in ACCUMULO-2127
>

--
CONFIDENTIALITY NOTICE
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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB