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 if you spot any problems or concerns.
Regarding
{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.
Kind regards
Angela
On 13/04/17 12:17, "Michael Dürig" <[email protected]> wrote:
>
>> I try to describe the changes proposed by the PoC in
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.a
>>pache.org%2Fjira%2Fbrowse%2FOAK-6073%3FfocusedCommentId%3D15965623%26pa&d
>>ata=02%7C01%7C%7Cd062470b1185427e793608d482565535%7Cfa7b1b5a7b34438794aed
>>2c178decee1%7C0%7C0%7C636276754686224956&sdata=W7sTOFt4hmoew%2BMR7K%2F45I
>>PvOAOSQPsaGKhWfMUWOuI%3D&reserved=0
>>
>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
>>nt
>> -15965623.
>> Additionally added some step-by-step instruction on how we proceeded.
>>
>
>Thanks, this is very valuable!
>
>
>> When we first looked at it on Tuesday last week, I thought that we would
>> end the exercise with a "tried hard but failed" summary. So, I am quite
>> pleased that actually ended up with a working PoC.
>
>So am I, I'm impressed by the progress here!
>
>
>> Looking back I thing the biggest issues are
>>
>> - putting everything in oak-core was obviously convenient but it turned
>> out to be impossible to protect against boundary violations
>> - packages sometimes contain classes that not really belong together,
>>e.g.
>> - org.apache.jackrabbit.oak.spi.lifecycle containing OakInitializer
>> - oak.apache.jackrabbit.oak.spi.whiteboard containing classes that
>> should be located with the corresponding feature (e.g. user mgt, index)
>> - impl specific methods that are not defined by an API contract such as
>> e.g. ValueImpl.getBlob, ValueImpl.getOakString... this was actually the
>> only place where we added a new interface and modified existing code
>> - somehow i got the impression that we didn't manage to make consistent
>> decision wrt package naming
>> - what should go into a 'spi' package?
>> - what should go into 'plugins'-something? and how is that different
>> from spi? (and what is e.g. the diff between spi.blob and plugins.blob?)
>> - when do we create a new package space oak.somethingnew and how are
>> those packages intended to be used.
>>
>> Moving forward I think it would help a lot if we had a common
>> understanding here and come up with some description what is used for
>>what.
>> Maybe we also need to take a closer look when adding new stuff to
>>oak-core
>> while moving forward.
>
>I think this is a discussion we need to take up again in the aftermath
>of this restructuring. For now I think it is best to create JIRA issue
>for those things you had to somehow work around or leave out.
>
>
>>
>>> Quick wins?
>>
>> Well... for me the biggest win is the fact that 'oak-blob-azure',
>> 'oak-blob-cloud' and 'oak-segment-tar' no longer would depend on
>>oak-core.
>
>+1, I'm specially happy with the result for oak-segment-tar. We already
>tried last year to make this module more independent but had to revert
>eventually.
>
>
>>> Looking at the list of modules, its size and the names, did you
>>>consider
>>> switching to a hierarchical module structure?
>>
>> No, we didn't discuss that.
>>
>>> Or could this make sense later on?
>>
>> I don't have any strong preference here. We had some discussion on how
>>we
>> should align the svn structure in general and what would be the best
>>when
>> we want to start releasing modules individually.
>>
>>> Otherwise can we come up with a naming scheme that implies
>>> grouping (e.g. node store implementations, blob store implementations,
>>> etc.)
>>
>> Sure, makes a lot of sense to me. :-)
>
>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.
>
>Michael
>>
>>>
>>> Re. oak-base and oak-commons, these are probably separated to avoid
>>> circular dependencies. Is there anyway to otherwise clarify the
>>> difference between the two? I.e. if I implement a new class, which
>>> module it should go into? Would oak-base be something like oak-core-spi
>>> or even oak-spi? This would nicely dual the oak-store-spi module.
>>
>> Exactly... and actually I like the name 'oak-core-spi' a lot better. In
>> OAK-6073 I stated that IMO that module might be a tmp solution as it
>> currently contains a somewhat loose collection of packages that were in
>> 'oak-core' and didn't really fit into 'oak-commons' from my point of
>>view.
>> After all I wanted to avoid converting 'oak-commons' into a second
>> 'oak-core' :-).
>> That module is the one with the least consistency IMO. But things may
>> clarify if we move on... I definitely would love to move
>>oak.spi.security
>> and oak.security.* out of oak-core... but that probably requires a
>>second
>> round *wishful thinking*.
>>
>>>
>>> Is there plans to move document/rdb stores to separate modules or is
>>> this beyond the current scope?
>>
>> I guess that would be a natural step as we move on... but during the
>>last
>> week we didn't look into this.
>>
>> Kind regards
>> Angela
>>
>> PS: will attach simplified picture to OAK-6073 to illustrated the big
>> picture.
>>
>>>
>>> Michael
>>>
>>> On 12.04.17 11:21, Angela Schreiber wrote:
>>>> 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 this in the near future.
>>>>
>>>> Consequently a group of oak devs started to work on a PoC on how to
>>>> improve modularisation of Oak (in particular oak-core). As we managed
>>>>to
>>>> get rid of the dependency of oak-blob-azure (and oak-segment-tar for
>>>> that
>>>> matter) from oak-core with a reasonable effort, we would like move
>>>> forward
>>>> with this in oak-trunk.
>>>>
>>>> For that matter I created a new epic "Modularisation of Oak" (OAK-6069
>>>> at
>>>> [1]) and added/linked a initial bunch of issues spotted during the
>>>> workshop and earlier. For the 'oak-blob-azure' topic I create a
>>>> dedicated
>>>> task OAK-6073 [2], where I will also add some detailed summary of the
>>>> initial effort. The latter can also be looked at on a github fork at
>>>> [3].
>>>>
>>>> Kind regards
>>>> Angela
>>>>
>>>> [0]
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmai
>>>>l.
>>>>
>>>>org%2Fmessage%2Fneoiyv5qsffo424e%3Fq%3Dazure%2Blist%3Aorg%252Eapache%25
>>>>2E
>>>>
>>>>ja&data=02%7C01%7C%7Cdcbd2fbcce2d43eed98208d4819aeae0%7Cfa7b1b5a7b34438
>>>>79
>>>>
>>>>4aed2c178decee1%7C0%7C0%7C636275949762279890&sdata=sSEdgDegV4Sigh5%2B5R
>>>>1y
>>>> uZQiMUY%2F7pOmvBhxojSpDV8%3D&reserved=0
>>>> ckrabbit%2Eoak-dev+from:%22Marcel+Reutegger%22&page=1
>>>> [1]
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>>>>.a
>>>>
>>>>pache.org%2Fjira%2Fbrowse%2FOAK-6069&data=02%7C01%7C%7Cdcbd2fbcce2d43ee
>>>>d9
>>>>
>>>>8208d4819aeae0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627594976
>>>>22
>>>> 89898&sdata=Gxu0MBcOz7zuobBRVSpofWBDJTV36T60bLH3Wmn1v5Q%3D&reserved=0
>>>> [2]
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>>>>.a
>>>>
>>>>pache.org%2Fjira%2Fbrowse%2FOAK-6073&data=02%7C01%7C%7Cdcbd2fbcce2d43ee
>>>>d9
>>>>
>>>>8208d4819aeae0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627594976
>>>>22
>>>> 89898&sdata=Xmxhr0gndLBTf4UvWiM50j7Q71yt13wpENm5SAeTVwo%3D&reserved=0
>>>> [3]
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
>>>>.c
>>>>
>>>>om%2Fmreutegg%2Fjackrabbit-oak%2Ftree%2Fm12n&data=02%7C01%7C%7Cdcbd2fbc
>>>>ce
>>>>
>>>>2d43eed98208d4819aeae0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636
>>>>27
>>>>
>>>>5949762289898&sdata=7gBCJs5NTQkAfvE6X0aAHSjaJsXlze9bPrTxBRFxXZE%3D&rese
>>>>rv
>>>> ed=0.
>>>>
>>
