Hey Sandeep - Sorry for the late response was on the road. Glad to hear you are in favor of the refactoring.
I think we need to determine the best way forward with that work in terms of git branches. Given that we generally create release line branches from master we need to make sure to not destabilize it while we work on the refactoring. It may make sense to create a separate branch for the refactoring work to keep master on existing package names for now. Then once we have the refactoring working reasonably well we can merge into master. I imagine that patches would need to be rationalized across branches during that time however. This may require separate patches for each branch until the merge happens. If we try and concentrate on the refactoring work for a couple weeks before we push many patches this pain can be minimized. We will also need to get some insights into as many custom user extensions that may exist as possible. This is the only way we will know exactly what adapter classes we will need to provide. Thoughts on these logistics would certainly be welcomed! thanks, --larry On Sun, Apr 2, 2017 at 10:31 AM, Sandeep More <[email protected]> wrote: > +1 for 1.0.0 release. > > About the package names, that seems to be a big refactoring change and a > needed one IMO (could be now or near future), with a lot of UnitTest and > other tests breaking (pure Knox tests, custom tests and third party tests) > as you rightly pointed out. > > I really like the idea of Shim classes to to avoid the test failures and > support the custom extensions. > Would love to know what folks think about it. > > Thank you for kicking off the discussion on 1.0.0 release Larry ! > > Best, > Sandeep > > > On Sat, Apr 1, 2017 at 6:50 PM, larry mccay <[email protected]> wrote: > >> All @devs and @users - >> >> With the 0.12.0 release behind us which concentrated on KIP-4 to improve >> the knoxshell SDK and DSL capabilities and maturity as well as other bug >> fixes and improvements, I think we should seriously consider a 1.0.0 >> release for Apache Knox. >> >> We have always tried to maintain backward compatibility across the >> releases >> anyway - so this will not be adding any additional burden. >> >> The one aspect that we do need to close on is the package names used by >> the >> project. >> >> Currently, we use a base of org.apache.hadoop.gateway for all of our java >> code. We should at least consider changing this to something like >> org.apache.knox.gateway. >> >> At the same time, we need to consider the backward compatibility aspects >> of >> this change and how it would effect a number of consumers: >> >> * folks that have extended existing abstract classes or implemented >> interfaces >> * folks that are running tests suites that have explicit classnames in >> configuration, etc >> * existing deployments that may upgrade to a 1.0.0 release and have >> {GATEWAY_HOME}/data/deployments directories full of descriptors with the >> current KnoxLdapRealm classname and package >> * any others? >> >> It would likely require some testing to ensure that our unit tests and any >> known system/functional tests that are running outside of dev environments >> pass. Which may require some shim classes in the old packages for known >> extension points and classes. >> >> A 1.0.0 release is an exciting milestone and I look forward to seeing it >> happen for our community! >> >> Any thoughts, concerns or ideas? >> >> thanks! >> >> --larry >> > >
