>> >> Sure... what modules do you think should be renamed? You mentioned >> oak-commons-run... anything else? > >Apart from renaming oak-commons-run to oak-run-commons there is: > >1) oak-authentication-* instead of oak-auth-* as this would be inline >with oak-authorization-*.
while i like the explicit naming i am not sure it's worth the trouble given the fact that the 'auth' modules have been around for such a long time. > >2) Also it is not obvious that oak-segment-tar and oak-store-spi are >related. From that POC oak-segment-tar should be something like >oak-store-segment. same here. if renaming was an option for those mainly working on segment-tar, i would suggest you create a jira issue. > >3) Further oak-example and oak-exercise: the former already has sub >modules. Maybe we can rename it to oak-getting-started (or similar) and >move oak-exercise into the renamed one. fine with me. whoever takes care of this: note that the documentation for oak security contains quite some references to the exercises. > >I'm actually reluctant about 1) and 2) as renaming established modules >have quite a ripple effect. As with 3) we already have sub-modules in >one place we should probably start a discussion of switching to a >hierarchical module structure. makes sense to me. >To address 1) and 2) once the main >modularisation effort stabilised. to be honest, i think we have more work ahead of us when looking at what remains in oak-core right now. i guess we would need another discussion here how we want to proceed with various plugins (mainly to comply with jcr), document nodestores, query and security. kind regards angela > >Michael > >> >> Kind regards >> Angela >> >> On 18/04/17 08:57, "Michael Dürig" <[email protected]> wrote: >> >>> >>> >>> On 13.04.17 15:52, Angela Schreiber wrote: >>>> {quote} >>>> I would suggest to go with a naming scheme that reflects how modules >>>> would be grouped together in a hierarchical structure as much as >>>> possible for now. E.g. rename oak-commons-run to oak-run-commons. >>>> {quote} >>>> >>>> I would like to address this separately as it would further expand the >>>> scope of OAK-6073, which will be open for review over the weekend. >>>>After >>>> that I would suggest that we incorporate the refactoring into >>>>oak-trunk. >>> >>> Works for me, but let's address it quickly afterwards so that those >>> "intermediate" module names do not get a chance to "stick around". >>> >>> Michael >>
