Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo, mail # dev - Hadoop 2 compatibility issues


+
Christopher 2013-05-14, 20:40
+
Sean Busbey 2013-05-14, 20:52
+
Christopher 2013-05-14, 21:39
+
John Vines 2013-05-14, 20:56
+
Benson Margulies 2013-05-14, 21:16
+
Adam Fuchs 2013-05-14, 21:35
+
Christopher 2013-05-14, 21:42
+
Christopher 2013-05-14, 21:48
+
Benson Margulies 2013-05-14, 21:51
+
Keith Turner 2013-05-14, 22:13
+
John Vines 2013-05-14, 22:16
+
Benson Margulies 2013-05-14, 23:09
+
John Vines 2013-05-14, 23:43
+
Christopher 2013-05-14, 23:36
+
Benson Margulies 2013-05-14, 23:41
+
Christopher 2013-05-14, 23:47
+
John Vines 2013-05-14, 23:50
+
Benson Margulies 2013-05-15, 00:27
+
Christopher 2013-05-15, 01:01
+
Adam Fuchs 2013-05-15, 21:31
+
Christopher 2013-05-15, 21:44
+
John Vines 2013-05-16, 00:03
+
Eric Newton 2013-05-16, 15:23
+
Adam Fuchs 2013-05-16, 15:51
+
John Vines 2013-05-14, 23:46
+
Josh Elser 2013-05-14, 23:36
Copy link to this message
-
Re: Hadoop 2 compatibility issues
John Vines 2013-05-14, 21:59
You're so quick to dismiss hadoop 2,but you really need to keep in mind how
pervasive it is. Even from our own software we can see how much people love
to run off of trunk, let alpha releases. But then one of the most popular
distributions, cdh, is more in line with it as well. Something to keep in
mind is that cdh3u5+ has hell of a lot in common with Hadoop 2 rather that
hadoop 1,with regard to api compatibilities. I'm sorry, but that's a user
base I would rather have some "unconventional" build code to support rather
than create an unnecessary headache for them and ourselves.

Sent from my phone, please pardon the typos and brevity.
On May 14, 2013 5:48 PM, "Christopher" <[EMAIL PROTECTED]> wrote:

> I think it's interesting that Option 4 seems to be most preferred...
> because it's the *only* option that is explicitly advised against by
> the Maven developers (from the information I've read). I can see its
> appeal, but I really don't think that we should introduce an explicit
> problem for users (that applies to users using even the Hadoop version
> we directly build against... not just those using Hadoop 2... I don't
> know if that point was clear), to only partially support a version of
> Hadoop that is still alpha and has never had a stable release.
>
> BTW, Option 4 was how I had have achieved a solution for
> ACCUMULO-1402, but am reluctant to apply that patch, with this issue
> outstanding, as it may exacerbate the problem.
>
> Another implication for Option 4 (the current "solution") is for
> 1.6.0, with the planned accumulo-maven-plugin... because it means that
> the accumulo-maven-plugin will need to be configured like this:
> <plugin>
>   <groupId>org.apache.accumulo</groupId>
>   <artifactId>accumulo-maven-plugin</artifactId>
>   <dependencies>
>    ... all the required hadoop 1 dependencies to make the plugin work,
> even though this version only works against hadoop 1 anyway...
>   </dependencies>
>   ...
> </plugin>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, May 14, 2013 at 5:42 PM, Christopher <[EMAIL PROTECTED]> wrote:
> > I think Option 2 is the best solution for "waiting until we have the
> > time to solve the problem correctly", as it ensures that transitive
> > dependencies work for the stable version of Hadoop, and using Hadoop2
> > is a very simple documentation issue for how to apply the patch and
> > rebuild. Option 4 doesn't wait... it explicitly introduces a problem
> > for users.
> >
> > Option 1 is how I'm tentatively thinking about fixing it properly in
> 1.6.0.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Tue, May 14, 2013 at 4:56 PM, John Vines <[EMAIL PROTECTED]> wrote:
> >> I'm an advocate of option 4. You say that it's ignoring the problem,
> >> whereas I think it's waiting until we have the time to solve the problem
> >> correctly. Your reasoning for this is for standardizing for maven
> >> conventions, but the other options, while more 'correct' from a maven
> >> standpoint or a larger headache for our user base and ourselves. In
> either
> >> case, we're going to be breaking some sort of convention, and while it's
> >> not good, we should be doing the one that's less bad for US. The
> important
> >> thing here, now, is that the poms work and we should go with the method
> >> that leaves the work minimal for our end users to utilize them.
> >>
> >> I do agree that 1. is the correct option in the long run. More
> >> specifically, I think it boils down to having a single module
> compatibility
> >> layer, which is how hbase deals with this issue. But like you said, we
> >> don't have the time to engineer a proper solution. So let sleeping dogs
> lie
> >> and we can revamp the whole system for 1.5.1 or 1.6.0 when we have the
> >> cycles to do it right.
> >>
> >>
> >> On Tue, May 14, 2013 at 4:40 PM, Christopher <[EMAIL PROTECTED]>
> wrote:
> >>
> >>> So, I've run into a problem with ACCUMULO-1402 that requires a larger
+
John Vines 2013-05-14, 21:52
+
Keith Turner 2013-05-14, 22:08
+
Sean Busbey 2013-05-14, 22:14
+
Eric Newton 2013-05-14, 23:23