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? > >>>> > >> > >
