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
Copy link to this message
-
Re: Hadoop 2 compatibility issues
On Tue, May 14, 2013 at 5:51 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:

> I am a maven developer, and I'm offering this advice based on my
> understanding of reason why that generic advice is offered.
>
> If you have different profiles that _build different results_ but all
> deliver the same GAV, you have chaos.
>

What GAV are we currently producing for hadoop 1 and hadoop 2?
>
> If you have different profiles that test against different versions of
> dependencies, but all deliver the same byte code at the end of the
> day, you don't have chaos.
>
>
>
> On Tue, May 14, 2013 at 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, 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
+
John Vines 2013-05-14, 21:59
+
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