Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Thu, 28 Aug 2014 22:11:28 -0700
From: Konstantin Boudnik <cos@apache.org>
To: dev@hbase.apache.org
Subject: Re: HBase shell compatibility needs [Was: Ruby scripting in HBase?]
Message-ID: <20140829051128.GD3753@tpx>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00"
Content-Disposition: inline
In-Reply-To: 
 <CAGHyZ6K4EEZe-0iGdVMJeP0vX3hzpK42EKZmQoaXsTc+jBVaWA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

--XWOWbaMNXpFDWE00
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sorry Sean - I've missed the thread somehow. So, yes - let's combine the tw=
o:
they are of course very closely related.

Cos

On Thu, Aug 28, 2014 at 11:23PM, Sean Busbey wrote:
> Hey Cos,
>=20
> A couple of weeks ago I started a thread on what kind of compatibility
> needs have to be met when updating the shell, which is the vast majority =
of
> our jruby.
>=20
> *http://s.apache.org/tFV <http://s.apache.org/tFV>*
>=20
> Can we combine discussions into one place over there?
>=20
> Ideally, I'd like to replace the jruby (at least for user facing
> operational needs) with a pure-java implementation that can cut down on
> size while getting faster. Unfortunately I got caught up in some work and
> the thread went quite. I'm going to try to address Stack's concerns
> tomorrow.
>=20
> My hope is that we can have language appropriate client bindings for folks
> who'd like to build their own tooling in a scripting language.
>=20
>=20
> On Thu, Aug 28, 2014 at 7:34 PM, Konstantin Boudnik <cos@apache.org> wrot=
e:
>=20
> > On Thu, Aug 28, 2014 at 07:51PM, Jean-Marc Spaggiari wrote:
> > > Was more thinking about the first. Having a way to automate groovy sh=
ell
> > > commands testing in the build.
> >
> > I am pretty sure there is. After all, Gradle (a build DSL based, using
> > Groovy
> > as the underlying language) has unit testing in it ;)
> >
> > The issue with testing of these scripts, as far as I can see, is that t=
hey
> > might need some sort of mocking involved to work around the fact that t=
hese
> > command expect a running HBase cluster. Makes sense?
> >
> > As for the 'pain vs pain' comment: I am not really sure why. Groovy is
> > really
> > just a Java with added benefits of real lambdas, dynamic bindings, etc.
> >
> > Cos
> >
> > > Le 2014-08-28 19:45, "Mikhail Antonov" <olorinbant@gmail.com> a =C3=
=A9crit :
> > >
> > > > JM - do you mean writing unit or integration tests for groovy comma=
nds
> > > > themselves, or to be able to write HBase tests in Groovy? If later
> > > > one, then I'd think HBase tests may benefit a lot in conciseness if
> > > > written in Groovy.
> > > >
> > > > -Mikhail
> > > >
> > > > 2014-08-28 16:39 GMT-07:00, Jean-Marc Spaggiari <
> > jean-marc@spaggiari.org>:
> > > > > Are we not just going to replace a pain by another pain?
> > > > >
> > > > > Can we build test suites for Groovy? I mean, not just use groovy =
to
> > build
> > > > > test, but build a test script which will test groovy? I think it's
> > one of
> > > > > the main issues today with JRuby shell.
> > > > >
> > > > > I prefer Groovy over JRuby but not sure if the move really worse =
it.
> > > > >
> > > > >
> > > > > 2014-08-28 19:06 GMT-04:00 Konstantin Boudnik <cos@apache.org>:
> > > > >
> > > > >> Guys,
> > > > >>
> > > > >> I've been looking into some service scripting around HBase lifec=
ycle
> > > > >> management, etc. and couldn't help but wonder why those were
> > written in
> > > > >> Ruby
> > > > >> of all JVM languages? Historical legacy aside, it seems that cur=
rent
> > > > >> HBase
> > > > >> is
> > > > >> still using JRuby 1.6.5 vs the latest at 1.9+ or perhaps even la=
ter.
> > > > >>
> > > > >> At any rate, I was wondering if replacing Ruby with a more Java-=
like
> > > > >> scripting
> > > > >> extension (if the scripting-2-Java API bridge is what indeed
> > desired)
> > > > >> would be
> > > > >> of any interest here? An obvious choice would be Groovy
> > > > >> (http://groovy.codehaus.org/). One of the main reasons behind my
> > > > proposal
> > > > >> is
> > > > >> stack simplification: Bigtop is very actively using Groovy as a
> > > > scripting
> > > > >> language of choice to do builds, develop smoke tests, etc. So, i=
t is
> > > > >> already
> > > > >> there and guaranteed to be installed as a part of any Bigtop-der=
ived
> > > > >> Hadoop
> > > > >> distro. There are other benefits, where, if desired, one can just
> > write
> > > > >> Java
> > > > >> code inside of a Groovy script, without a need to learn yet anot=
her
> > > > >> language
> > > > >> like Ruby.
> > > > >>
> > > > >> This is perhaps not of an immediate priority for the community, =
but
> > if
> > > > >> there's
> > > > >> enough interest, I can give it an initial shot to demo'ed what I=
 am
> > > > >> really
> > > > >> talking about.
> > > > >>
> > > > >> Thoughts?
> > > > >> --
> > > > >> Regards,
> > > > >>   Cos
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Michael Antonov
> > > >
> >
>=20
>=20
>=20
> --=20
> Sean

--XWOWbaMNXpFDWE00
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAlQAC4AACgkQenyFlstYjhI0zAD/dlyptG29R7+k+8fTXfMHcXkO
vRhwQKLtlj3zX58d8sUA/0Fbxi4nksBtQntYr/l9uJxrxydEKuu6SfSF5wXB721w
=3mBZ
-----END PGP SIGNATURE-----

--XWOWbaMNXpFDWE00--