Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB