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

Switch to Plain View
Accumulo, mail # dev - Releasing 1.5


+
John Vines 2013-04-25, 17:48
+
Keith Turner 2013-04-25, 17:56
+
John Vines 2013-04-25, 18:03
+
Keith Turner 2013-04-25, 18:09
+
Christopher 2013-04-25, 18:32
+
John Vines 2013-04-25, 18:54
+
Keith Turner 2013-04-25, 19:32
+
Josh Elser 2013-04-25, 19:37
+
John Vines 2013-04-25, 19:46
+
Keith Turner 2013-04-25, 19:57
+
Josh Elser 2013-04-25, 20:06
+
Keith Turner 2013-04-25, 20:30
+
Benson Margulies 2013-04-25, 20:41
+
Keith Turner 2013-04-26, 12:42
+
David Medinets 2013-04-26, 19:32
+
Billie Rinaldi 2013-04-26, 20:19
+
John Vines 2013-04-26, 20:35
+
Billie Rinaldi 2013-04-26, 21:47
+
Christopher 2013-04-26, 23:24
+
Josh Elser 2013-04-30, 04:01
+
John Vines 2013-04-30, 04:32
+
John Vines 2013-05-07, 15:10
+
Christopher 2013-05-07, 15:23
Copy link to this message
-
Re: Releasing 1.5
John Vines 2013-05-07, 15:28
I am more than content with that assessment
On Tue, May 7, 2013 at 11:23 AM, Christopher <[EMAIL PROTECTED]> wrote:

> I would love to deploy additional artifacts using classifiers for
> hadoop2. We may be able to support that for the jar artifacts in
> Maven, with some minor profile tweaks to the POM. (Apache
> infrastructure actually allows you to deploy many artifacts to a
> staging repo, before closing that staging repo... so it's not
> impossible to stage all the hadoop1 stuff, then stage some additional
> stuff). I'll try that for RC2 (is there already a ticket open for
> this?). However, the assemble module already uses classifiers because
> multiple DEBs/RPMs are built in a single module (not following Maven
> conventions), so it's going to take some additional project
> refactoring in 1.6 before we could put out different
> RPMs/DEBs/tarballs for hadoop2. I'm going to go out on a limb here and
> say that the Maven artifacts for hadoop2 would be good enough for 1.5.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, May 7, 2013 at 11:10 AM, John Vines <[EMAIL PROTECTED]> wrote:
> > I would also like to point out that hbase is putting out separate
> releases
> > for hadoop1 and hadoop2 (
> > http://www.apache.org/dyn/closer.cgi/hbase/hbase-0.95.0). They also have
> > support for both via maven, however they implemented a compatibility
> module
> > (https://issues.apache.org/jira/browse/HBASE-6405) which brings the
> schism
> > down to a single jar that needs to be interchanged. That may be something
> > we want to consider for 1.6.
> >
> > The reason that I care about this is I'm working on things on top of
> > Accumulo, but against multiple versions of hadoop. I want to be able to
> > easily able to build against different versions of Accumulo 1.5 without
> > have to kill my local repo, reinstall accumulo built against my target
> > version of hadoop, etc. etc. It would be SOOOO much more convenient to
> just
> > switch my accumulo version from 1.5 to 1.5-hadoop2 and be done with it.
> >
> >
> > On Tue, Apr 30, 2013 at 12:32 AM, John Vines <[EMAIL PROTECTED]> wrote:
> >
> >> I've always been an advocate of sticking to vanilla compatibility, but
> >> maintaining ability to be compatible with other versions. Hadoop 2ish
> >> things are the first case where we are beginning to see broken run-time
> >> compatibility due to some API changes. While the fragmented state of
> hadoop
> >> creates a larger set of jars, even just hadoop 1 vs. hadoop2 is enough
> to
> >> break things. I think priority number 1 should be compile time
> >> compatibility with everything, followed by attempts for full runtime
> >> compatibility. Obviously this can't happen, but it can be achieved by
> >> identical source but split compiled resources, and I think that may be
> >> something we have to do. If we're putting in the legwork to know how to
> >> successfully run against hadoop_variant_8271, we may as well provide a
> >> compiled unit for it as well.
> >>
> >>
> >> On Tue, Apr 30, 2013 at 12:01 AM, Josh Elser <[EMAIL PROTECTED]>
> wrote:
> >>
> >>> Funny enough, I gothit by these shenanigans last night when I was
> trying
> >>> to run trunk against CDH3 locally. After working through jars that were
> >>> marked asprovidedand weren't, and then running into
> >>> https://issues.apache.org/**jira/browse/ACCUMULO-837<
> https://issues.apache.org/jira/browse/ACCUMULO-837>,
> >>> I threw in the towel and called it a night.
> >>>
> >>> I think one thing we can all agree upon is that the "fragmented" state
> of
> >>> Hadoop distributions is a pain to work around; however, we do have a
> very
> >>> broad coverage across that variance just on our committer list.
> Considering
> >>> Benson's comments on the subject of "supporting" non-Apache Hadoop
> >>> variants, I would think that it's in our best interest to provide some
> >>> level of warm-fuzzy in terms of support. I'm worried about making
> people
> >>> chase their tails just to get Accumulo up and running on their flavor
+
David Medinets 2013-05-07, 16:38
+
Christopher 2013-04-25, 19:11