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