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
HBase >> mail # dev >> Declaring HBase Public API in 0.94


+
Aleksandr Shulman 2013-04-08, 18:07
+
Elliott Clark 2013-04-08, 20:49
+
Ted Yu 2013-04-08, 21:24
+
Todd Lipcon 2013-04-08, 21:50
Copy link to this message
-
Re: Declaring HBase Public API in 0.94
> Given that it's only annotations, you also may be able to pull in the
Hadoop 2 annotations package without all of common (I believe it's a
separate maven artifact)

I fear that will cause even more problems, since 0.94 will still be run
against 0.23, and 2.x. I would vote for bringing the annotations in if we
would go that route.

Enis
On Mon, Apr 8, 2013 at 2:50 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> There's always the option of duplicating those annotations into the HBase
> package if you want to annotate 0.94 without depending on Hadoop 2.
>
> Given that it's only annotations, you also may be able to pull in the
> Hadoop 2 annotations package without all of common (I believe it's a
> separate maven artifact)
>
> -Todd
>
> On Mon, Apr 8, 2013 at 2:24 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > bq. Keeping 0.2x compatibility was something that was hard won in 0.94
> >
> > True. We should maintain this status.
> >
> > On Mon, Apr 8, 2013 at 1:49 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:
> >
> > > Please don't pull in @InterfaceAudience.  Keeping 0.2x compatibility
> was
> > > something that was hard won in 0.94, it would be a real shame to loose
> > that
> > > now.
> > >
> > >
> > > On Mon, Apr 8, 2013 at 11:07 AM, Aleksandr Shulman <[EMAIL PROTECTED]
> > > >wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > In light of all the conversation on compatibility, I wanted to float
> > the
> > > > idea of documenting which Java packages, classes, and methods we want
> > to
> > > > declare as being API compatible in 0.94.x. I'd like your input on:
> > > > 1. JavaDoc vs. using AudienceInterface
> > > > 2. What the javadoc notation should look like
> > > > 3. Which pieces of code should be tagged
> > > >
> > > > What do I mean by documenting API compatibility? That means that we
> > > suggest
> > > > the anyone building applications use specific methods because they
> > would
> > > > continue to be both binary and RPC-compatible going forward. Any
> > > > application written, either running on a node of a cluster or on a
> > remote
> > > > machine, would continue to work properly without recompile for all
> > > versions
> > > > of 0.94.x running on the cluster.
> > > >
> > > > *Benefits:*
> > > > It would prevent developers from using calls that are subject to
> > change.
> > > > This would give developers more confidence in using the platform,
> which
> > > > will encourage more development on our platform.
> > > > 0.94 will still be with us for some time and I think the
> > > > better-late-than-never approach will save us pain down the road.
> > Finally,
> > > > it would allow us to more easily verify that we are in fact API
> > > compatible.
> > > >
> > > > *Can we use AudienceInterface?*
> > > > HBase 0.94 can be compiled against both hadoop 0.2x, 1.x, and 2.0.x.
> In
> > > the
> > > > case of 0.2x, the AudienceInterface classes were not bundled.
> > Therefore,
> > > we
> > > > cannot expect HBase 0.94 to support it. For that reason, I think
> > JavaDoc
> > > > might be better.
> > > > On the other hand, perhaps we might just want to bundle
> > AudienceInterface
> > > > with 0.94 going forward? Then we can have consistent annotations in
> > 0.94,
> > > > 0.95, and 0.96 without worrying about the hadoop version.
> > > >
> > > > Please correct me if I'm wrong about any of the above.
> > > >
> > > > *Clarification of RPC compatibility:*
> > > > We care about RPC compatibility when we create clients that bundle
> > their
> > > > dependency jars with them. These jars are used to form a request that
> > is
> > > > executed on a remote machine (i.e. the cluster). If the cluster is
> > > upgraded
> > > > and no longer recognizes the command, then this will break RPC
> > > > compatibility.
> > > >
> > > > *Clarification of Binary compatibility:*
> > > > We care about binary compatibility when a client is created and
> > compiled,
> > > > and the jars on which is depends change. It should still be able to
> > form
> > > > requests using those jars. If the cluster is upgraded and the
+
lars hofhansl 2013-04-08, 22:08
+
Todd Lipcon 2013-04-08, 22:55
+
Aleksandr Shulman 2013-04-09, 17:47
+
Aleksandr Shulman 2013-04-16, 20:56
+
Nick Dimiduk 2013-04-16, 21:14
+
Aleksandr Shulman 2013-04-17, 18:01
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