I've a patch for HADOOP-11102 which rolls curator back to v 2.4.1, which
only pulls in Guava 14...hadoop should now be weakly consistent -at least
not "strongly inconsistent"- in its guava versions.
allowing hadoop to work on 16.x while still remaining compatible with 11.x
is still something to wo
The use of an unnecessarily old dependency encourages problems like
HDFS-7040. The current Guava dependency is a big problem for downstream
apps and I'd really like to see it addressed.
On Tue, Sep 23, 2014 at 2:09 PM, Steve Loughran
wrote:
> I'm using curator elsewhere, it does log a lot (as d
I'm using curator elsewhere, it does log a lot (as does the ZK client), but
it solves a lot of problem. It's being adopted more downstream too.
I'm wondering if we can move the code to the extent we know it works with
Guava 16, with the hadoop core being 16-compatible, but not actually
migrated to
At the same time, not being able to use Curator will require a lot of extra
code, a lot of which we probably already have from the ZKRMStateStore, but
it's not available to use in hadoop-auth. We'd need to create our own ZK
libraries that Hadoop components can use, but (a) that's going to take a
w
If we've broken compatibility in branch-2, that's a bug that we need to
fix. HADOOP-10868 has not yet made it into a release; I don't see it as a
justification for solidifying the breakage.
-1 to upgrading Guava in branch-2.
On Tue, Sep 23, 2014 at 3:06 AM, Steve Loughran
wrote:
> +1 to upgradi
+1 to upgrading guava. Irrespective of downstream apps, the hadoop source
tree is now internally inconsistent
On 22 September 2014 17:56, Sangjin Lee wrote:
> I agree that a more robust solution is to have better classloading
> isolation.
>
> Still, IMHO guava (and possibly protobuf as well) sti
I agree that a more robust solution is to have better classloading
isolation.
Still, IMHO guava (and possibly protobuf as well) sticks out like a sore
thumb. There are just too many issues in trying to support both guava 11
and guava 16. Independent of what we may do with the classloading
isolatio
On 21 September 2014 23:11, Karthik Kambatla wrote:
> Upgrading Guava version is tricky. While it helps in many cases, it can
> break existing applications/deployments. I understand we do not have a
> policy for updating dependencies, but still we should be careful with
> Guava.
>
I agree, but t
Upgrading Guava version is tricky. While it helps in many cases, it can
break existing applications/deployments. I understand we do not have a
policy for updating dependencies, but still we should be careful with
Guava.
I would be more inclined towards a more permanent solution to this problem
- h
I would also agree on upgrading guava. Yes I am aware of the potential
impact on customers who might rely on hadoop bringing in guava 11. However,
IMHO the balance tipped over to the other side a while ago; i.e. I think
there are far more people using guava 16 in their code and scrambling to
make t
I know we've been ignoring the Guava version problem, but HADOOP-10868
added a transitive dependency on Guava 16 by way of Curator 2.6.
Maven currently forces the build to use Guava 11.0.2, but this is hiding at
compile timeall code paths from curator which may use classes & methods
that aren't th
11 matches
Mail list logo
