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
Copy link to this message
-
Re: Hadoop 2 compatibility issues
John Vines 2013-05-14, 22:16
They're the same currently. I was requesting separate gavs for hadoop 2.
It's been on the mailing list and jira.

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

> 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
+
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