I have done that exercise in the past as part of bigger exercise of bringing all the patches from sentry-ha branch to master. I had some issues with this refactoring change so it was not done in master.
*Thanks,Kalyan Kumar Kalvagadda* | Software Engineer t. (469) 279- <0000000000>5732 cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ On Wed, Apr 18, 2018 at 3:55 PM, Alexander Kolbasov <ak...@cloudera.com> wrote: > In my experience IntelliJ is your friend here - it is really good at this > kind of refactoring. > > On Wed, Apr 18, 2018 at 1:54 PM, Stephen Moist <mo...@cloudera.com> wrote: > > > Ok, I’ll work against that idea then with the sentry-service module. > > > > > On Apr 18, 2018, at 3:45 PM, Alexander Kolbasov <ak...@cloudera.com> > > wrote: > > > > > > It was done earlier as sentry-1205. The code is still in the got > > history. We didn't include the change - it was too difficult to merge > with > > ha branch. > > > > > >> On Apr 18, 2018, at 12:57, Stephen Moist <mo...@cloudera.com> wrote: > > >> > > >> Great, I’ll get started on that. Is there a better name I should use > > or is everyone fine with sentry-main. I noticed there was a > sentry-service > > module that is not used, perhaps that’s a bit better? > > >> > > >>> On Apr 18, 2018, at 2:05 PM, Sergio Pena <sergio.p...@cloudera.com> > > wrote: > > >>> > > >>> There have been concerns from other teams about the > sentry-provider-db > > as > > >>> well. > > >>> I think it makes sense to split it to avoid these dependencies > issues. > > >>> > > >>> Go head, create some jiras to split them. I will recommend creating > one > > >>> jira per module just to keep the patch simple and easy to review. > > >>> > > >>> > > >>> On Wed, Apr 18, 2018 at 12:24 PM, Anthony Young-Garner < > > >>> anthony.young-gar...@cloudera.com> wrote: > > >>> > > >>>> I agree that it would be useful to break up the sentry-provider-db > > module > > >>>> in order to allow dependency chains to be more easily expressed and > to > > >>>> decouple the SentryService entry point from the database model. Are > > there > > >>>> any concerns with the approach Steve suggested? > > >>>> > > >>>> On Wed, Apr 18, 2018 at 11:07 AM, Stephen Moist <mo...@cloudera.com > > > > >>>> wrote: > > >>>> > > >>>>> So looking at sentry-provider-db, it looks like it’s pretty much > the > > main > > >>>>> module of Sentry. It has the thrift apis, db, cli and Sentry > > Service. > > >>>> I’m > > >>>>> running into issues with developing ABAC as we have it be it’s own > > >>>> module. > > >>>>> It depends on sentry-provider-db, and then for me to add it in so > > that > > >>>>> SentryService can take advantage of it, sentry-provider-db depends > on > > >>>>> sentry-abac so we end up with a circular dependency. Rather than > > just > > >>>>> shove abac into sentry-provider-db, I’m proposing we split > > >>>>> sentry-provider-db into sentry-provider-db (the existing db layer), > > >>>>> sentry-main/sentry-service, sentry-main/sentry-cli and > > >>>>> sentry-main/sentry-api. Thus the dependency chain would be > > >>>>> sentry-provider-db -> sentry-service -> sentry-api->sentry-cli and > > >>>>> sentry-abac depends on sentry-service, sentry-cli, sentry-api. > > Thoughts > > >>>> on > > >>>>> this? > > >>>> > > >> > > > > >
