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 <[email protected]> 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 <[email protected] > >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" <[email protected]> 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 > > >
