I agree.
We should still be diligent in keeping dependencies up-to-date as long as
the changes are fairly non-destructive (I hear you about guava). That would
be a pretty big service to not only users but also developers of libraries
on hadoop.
On Fri, Mar 28, 2014 at 11:04 AM, Steve Loughran wr
Yes, we've been recommending the use of the classloader option. I think it
is a viable solution to the version clash problem. We're not very enthused
about the classpath.first config because you could trade one set of
problems for another.
Judging from some issues still being discovered (MAPREDUCE
On 29 March 2014 02:41, Andrew Wang wrote:
> We've successfully supported CDH4.2+ on Java 7 as well as CDH5, so I think
> that code wise we're ready to move to 7.
We're already supporting Java7 and openjdk7. OpenJDK doesn't seem any
different in terms of reliability. One resource leak during s
We've successfully supported CDH4.2+ on Java 7 as well as CDH5, so I think
that code wise we're ready to move to 7. However, we can't start using Java
7-only features in the 2.x line for compatibility reasons.
Also, even if the compatibility guidelines state that we can bump our
dependencies whene
I think we need some way of isolating YARN, MR, and HDFS clients from
the Hadoop dependencies. Anything else just isn't sane... whatever we
may say, there will always be clients that rely on the dependencies
that we pull in, if we make those visible. I can't really blame
clients for this. It's s
Regarding JDK7, we have at least one jira I'm aware of proposing several
improvements that we can make in our code by using new JDK7 APIs.
https://issues.apache.org/jira/browse/HADOOP-9590
If anyone wants to repurpose this as a master JDK7 enhancement jira and
start cataloging additional improvem
On 28 March 2014 17:00, Sandy Ryza 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
Given the fact that Java 6 is EOL for a while, I wonder, when is a good
time to drop the support of java 6 in trunk?
New functionalities in JDK7 such as file system watcher can simplify the
implementation of the name node and the data node in HDFS.
On Fri, Mar 28, 2014 at 10:30 AM, Steve Loughra
I don't disagree about version age -I've just been downgrading a project to
use some of the versions. The issue with YARN apps is that you get these on
your classpath.
1. There's a JIRA: https://issues.apache.org/jira/browse/HADOOP-9991
2. Nobody is working full time on these, I sporadicall
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.class
Hi folks,
Even as 2.3 was released, several dependencies of hadoop are quite dated.
And more and more of them are causing friction for hadoop-related libraries
and hadoop users in general, as these dependency versions are often
incompatibly different than the versions most people use these days. S
11 matches
Mail list logo
