0.94 non-secure tarballs

[lars hofhansl <la...@apache.org>]

I am thinking to stop releasing the tarballs without the security code. They do not really add anything, the secure tarballs work perfectly OK without security. The secure builds just have some source and class files.

I would also get rid of the non-secure build completely and just have one way to build HBase.

Any objections? Are there any other reasons to build both a secure and non-secure tarball? Export restrictions, or anything?

I think that would also make it trivial to release the secure bits to maven (but maven is black magic to me, so I do not know for sure).

-- Lars

Re: 0.94 non-secure tarballs

[lars hofhansl <la...@apache.org>]

Cool. Thanks Jesse, Stack, and Gary.
I filed a ticket to do so... And probably mess up the pom horribly until somebody shows me how to it.

-- Lars



________________________________
 From: Gary Helmling <gh...@gmail.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org> 
Sent: Thursday, March 27, 2014 10:04 AM
Subject: Re: 0.94 non-secure tarballs
 

+1, seems fine to eliminate the non-secure builds now.

The main reason for doing security as a separate profile was to make it
possible to continue to build and run HBase on a pre-1.0 Hadoop (Hadoop
without the security classes referenced in the HBase security code).  We
don't even have a profile for a non-secure Hadoop anymore, so I can't see
this being an issue any longer.



On Wed, Mar 26, 2014 at 9:39 PM, Jesse Yates <je...@gmail.com>wrote:

> +1
>
> Might need a good set of documentation the first couple times, but seems
> reasonable.
> On Mar 26, 2014 9:04 PM, "lars hofhansl" <la...@apache.org> wrote:
>
> > I am thinking to stop releasing the tarballs without the security code.
> > They do not really add anything, the secure tarballs work perfectly OK
> > without security. The secure builds just have some source and class
> files.
> >
> > I would also get rid of the non-secure build completely and just have one
> > way to build HBase.
> >
> > Any objections? Are there any other reasons to build both a secure and
> > non-secure tarball? Export restrictions, or anything?
> >
> > I think that would also make it trivial to release the secure bits to
> > maven (but maven is black magic to me, so I do not know for sure).
> >
> > -- Lars
>

Re: 0.94 non-secure tarballs

[Enis Söztutar <en...@gmail.com>]

+1.

I think it was needed for compiling with hadoop-0.20.x versions which did
not support security.

Enis


On Thu, Mar 27, 2014 at 10:14 AM, Stack <st...@duboce.net> wrote:

> Good by me.  Was done for historical reasons and because the fellas adding
> security were gracious, being careful, ensuring security did not impinge on
> non-secure deploys.  We are in a different place now: i.e. underlying
> hadoop versions now support it and security is no longer a rare
> consideration.
>
> St.Ack
>
>
> On Thu, Mar 27, 2014 at 10:04 AM, Gary Helmling <gh...@gmail.com>
> wrote:
>
> > +1, seems fine to eliminate the non-secure builds now.
> >
> > The main reason for doing security as a separate profile was to make it
> > possible to continue to build and run HBase on a pre-1.0 Hadoop (Hadoop
> > without the security classes referenced in the HBase security code).  We
> > don't even have a profile for a non-secure Hadoop anymore, so I can't see
> > this being an issue any longer.
> >
> >
> > On Wed, Mar 26, 2014 at 9:39 PM, Jesse Yates <jesse.k.yates@gmail.com
> > >wrote:
> >
> > > +1
> > >
> > > Might need a good set of documentation the first couple times, but
> seems
> > > reasonable.
> > > On Mar 26, 2014 9:04 PM, "lars hofhansl" <la...@apache.org> wrote:
> > >
> > > > I am thinking to stop releasing the tarballs without the security
> code.
> > > > They do not really add anything, the secure tarballs work perfectly
> OK
> > > > without security. The secure builds just have some source and class
> > > files.
> > > >
> > > > I would also get rid of the non-secure build completely and just have
> > one
> > > > way to build HBase.
> > > >
> > > > Any objections? Are there any other reasons to build both a secure
> and
> > > > non-secure tarball? Export restrictions, or anything?
> > > >
> > > > I think that would also make it trivial to release the secure bits to
> > > > maven (but maven is black magic to me, so I do not know for sure).
> > > >
> > > > -- Lars
> > >
> >
>

Re: 0.94 non-secure tarballs

[Stack <st...@duboce.net>]

Good by me.  Was done for historical reasons and because the fellas adding
security were gracious, being careful, ensuring security did not impinge on
non-secure deploys.  We are in a different place now: i.e. underlying
hadoop versions now support it and security is no longer a rare
consideration.

St.Ack


On Thu, Mar 27, 2014 at 10:04 AM, Gary Helmling <gh...@gmail.com> wrote:

> +1, seems fine to eliminate the non-secure builds now.
>
> The main reason for doing security as a separate profile was to make it
> possible to continue to build and run HBase on a pre-1.0 Hadoop (Hadoop
> without the security classes referenced in the HBase security code).  We
> don't even have a profile for a non-secure Hadoop anymore, so I can't see
> this being an issue any longer.
>
>
> On Wed, Mar 26, 2014 at 9:39 PM, Jesse Yates <jesse.k.yates@gmail.com
> >wrote:
>
> > +1
> >
> > Might need a good set of documentation the first couple times, but seems
> > reasonable.
> > On Mar 26, 2014 9:04 PM, "lars hofhansl" <la...@apache.org> wrote:
> >
> > > I am thinking to stop releasing the tarballs without the security code.
> > > They do not really add anything, the secure tarballs work perfectly OK
> > > without security. The secure builds just have some source and class
> > files.
> > >
> > > I would also get rid of the non-secure build completely and just have
> one
> > > way to build HBase.
> > >
> > > Any objections? Are there any other reasons to build both a secure and
> > > non-secure tarball? Export restrictions, or anything?
> > >
> > > I think that would also make it trivial to release the secure bits to
> > > maven (but maven is black magic to me, so I do not know for sure).
> > >
> > > -- Lars
> >
>

Re: 0.94 non-secure tarballs

[Gary Helmling <gh...@gmail.com>]

+1, seems fine to eliminate the non-secure builds now.

The main reason for doing security as a separate profile was to make it
possible to continue to build and run HBase on a pre-1.0 Hadoop (Hadoop
without the security classes referenced in the HBase security code).  We
don't even have a profile for a non-secure Hadoop anymore, so I can't see
this being an issue any longer.


On Wed, Mar 26, 2014 at 9:39 PM, Jesse Yates <je...@gmail.com>wrote:

> +1
>
> Might need a good set of documentation the first couple times, but seems
> reasonable.
> On Mar 26, 2014 9:04 PM, "lars hofhansl" <la...@apache.org> wrote:
>
> > I am thinking to stop releasing the tarballs without the security code.
> > They do not really add anything, the secure tarballs work perfectly OK
> > without security. The secure builds just have some source and class
> files.
> >
> > I would also get rid of the non-secure build completely and just have one
> > way to build HBase.
> >
> > Any objections? Are there any other reasons to build both a secure and
> > non-secure tarball? Export restrictions, or anything?
> >
> > I think that would also make it trivial to release the secure bits to
> > maven (but maven is black magic to me, so I do not know for sure).
> >
> > -- Lars
>

Re: 0.94 non-secure tarballs

[Jesse Yates <je...@gmail.com>]

+1

Might need a good set of documentation the first couple times, but seems
reasonable.
On Mar 26, 2014 9:04 PM, "lars hofhansl" <la...@apache.org> wrote:

> I am thinking to stop releasing the tarballs without the security code.
> They do not really add anything, the secure tarballs work perfectly OK
> without security. The secure builds just have some source and class files.
>
> I would also get rid of the non-secure build completely and just have one
> way to build HBase.
>
> Any objections? Are there any other reasons to build both a secure and
> non-secure tarball? Export restrictions, or anything?
>
> I think that would also make it trivial to release the secure bits to
> maven (but maven is black magic to me, so I do not know for sure).
>
> -- Lars