Re: [m12] Effort to Improve Modularisation of Oak

hi michael i created OAK-6101 as task of OAK-6069 to track any work wrt consistent naming of oak modules. will ping davide there wrt renaming of oak-commons-run kind regards angela On 19/04/17 16:33, "Michael Dürig" wrote: > > >On 19.04.17 16:26

Re: [m12] Effort to Improve Modularisation of Oak

On 19.04.17 16:26, Angela Schreiber wrote: 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 t

Re: [m12] Effort to Improve Modularisation of Oak

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

Re: [m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

hi julian for the sake of simplicity (and to see where the pain points would be) i just tried to refactor all of plugins.document out of oak-core. that already seems to require some more effort than i expected. maybe it would make sense to at least define to long term goal and make sure new code

Re: [m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

On 2017-04-19 14:09, Angela Schreiber wrote: hi oak-devs michael asked about m12n effort for document nodestore: On 12/04/17 13:56, "Michael Dürig" wrote: [...] Is there plans to move document/rdb stores to separate modules or is this beyond the current scope? [...] i had a quick look th

Re: [m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

Hi, On 19/04/17 14:09, Angela Schreiber wrote: > i had a quick look this morning and got the impression that we would need > some extra effort to be able to move document/rdb stores to separate > modules. in particular it seems that we got circular dependencies between > plugins.document.* and oth

[m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

hi oak-devs michael asked about m12n effort for document nodestore: On 12/04/17 13:56, "Michael Dürig" wrote: [...] > >Is there plans to move document/rdb stores to separate modules or is >this beyond the current scope? > [...] i had a quick look this morning and got the impression that we wou

Re: [m12] Effort to Improve Modularisation of Oak

On 19/04/2017 08:14, Michael Dürig wrote: > 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. +1. Please also check the deployment of each module. I don't think we

Re: [m12] Effort to Improve Modularisation of Oak

On 18.04.17 14:51, Angela Schreiber wrote: Hi Michael 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

Re: [m12] Effort to Improve Modularisation of Oak

Hi Just a quick heads up: the refactoring (without the extra renaming proposed by Michael) has been committed at revision 1791779. Did my best to avoid breaking anything, checking individual modifications as well as running the build including ITs. I would still ask everyone to quickly verify if

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael Sure... what modules do you think should be renamed? You mentioned oak-commons-run... anything else? Kind regards Angela On 18/04/17 08:57, "Michael Dürig" wrote: > > >On 13.04.17 15:52, Angela Schreiber wrote: >> {quote} >> I would suggest to go with a naming scheme that reflects h

Re: [m12] Effort to Improve Modularisation of Oak

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 separa

Re: [m12] Effort to Improve Modularisation of Oak

Hi Matt, On Thu, 2017-04-13 at 09:07 -0600, Matt Ryan wrote: > Great work so far to everyone involved in this effort. > > I'm under the impression that this refactoring will constitute a > change in > the public API contract of Oak.  In reading the links it seems to > hint at > this but whether o

Re: [m12] Effort to Improve Modularisation of Oak

Great work so far to everyone involved in this effort. I'm under the impression that this refactoring will constitute a change in the public API contract of Oak. In reading the links it seems to hint at this but whether or not this will actually result in a public API change isn't explicitly call

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael and Oak-Devs Just a quick update: I added more details to OAK-6073 included a summary of the effects on oak-core and oak-commons as well as listing changes to non-test dependencies of most modules. I would like to encourage you to look at the fork and the summary and provide feedback i

Re: [m12] Effort to Improve Modularisation of Oak

I try to describe the changes proposed by the PoC in https://issues.apache.org/jira/browse/OAK-6073?focusedCommentId=15965623&pa ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment -15965623. Additionally added some step-by-step instruction on how we proceeded. Thanks,

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael I try to describe the changes proposed by the PoC in https://issues.apache.org/jira/browse/OAK-6073?focusedCommentId=15965623&pa ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment -15965623. Additionally added some step-by-step instruction on how we proceeded.

Re: [m12] Effort to Improve Modularisation of Oak

Hi Angela, Thanks for driving this and coming up with a PoC. I like the direction this is taking. The module boundaries make sense to me and having certain dependencies de-tangled will certainly be helpful going forward. Could you share a bit of your experience doing this refactoring? What we

[m12] Effort to Improve Modularisation of Oak

Hi As mentioned my Marcel this morning [0] we had some offline discussions related to the oak-blob-azure module and how we could independently release it. While we didn't see a satisfying solution for the 1.6 branch, we concluded that we should pick up the modularisation discussion for address th