Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

[Robert Munteanu]

I created a final PR for this as I have somewhat mixed feelings. One
one had, it finally nukes the util package. On the other hand, it looks
like a lot of noise for 3 classes.

  https://github.com/mreutegg/jackrabbit-oak/pull/6

Robert

On Thu, 2017-04-06 at 14:49 +, Angela Schreiber wrote:
> Hi Robert
> 
> plugins.tree would feel natural to me.
> regarding the export: not sure about that either... the plugins.tree
> has
> some unfortunate dependencies e.g. to oak.core. so probably more work
> ahead in that area.
> 
> kind regards
> angela
> 
> On 06/04/17 16:41, "Robert Munteanu"  wrote:
> 
> > Hi,
> > 
> > Working in the m12n branch [1] I'm trying to get rid of the
> > o.a.j.oak.util package and the last surviving members are
> > ApproximateCounter, NodeUtil and TreeUtil.
> > 
> > As I see it these classes are essentially helpers built on top of
> > the
> > Tree and NodeState APIs. Those would make them candidates on for
> > either
> > oak-store-spi or (if we manage to trim down the dependencies) oak-
> > base.
> > 
> > However I am having trouble naming the package which will hold
> > them.
> > They're not part of the spi, so I can't put them in spi.state .
> > 
> > Maybe they belong in oak-core in plugins.tree, but I'm not sure if
> > we
> > want to keep that as a package which is exported outside oak-core.
> > 
> > Thoughts?
> > 
> > Robert
> > 
> > [1]: 
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.co
> > m%2Fmreutegg%2Fjackrabbit-
> > oak%2Ftree%2Fm12n=02%7C01%7C%7Cbfc1feb5ff4a
> > 4866c79c08d47cfafe6d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
> > 3627086
> > 4841267177=CWwq4ifTZIU1gW9UEd2STRLm%2B1svSP0kvlkLMksmWcM%3D
> > eserved
> > =0
> 
> 

Re: [m12] Effort to Improve Modularisation of Oak

[Robert Munteanu]

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 or not this will actually result in a public API
> change
> isn't explicitly called out.
> 
> So my first question:  Is my impression accurate here?

It is accurate to a certain degree. There is no change for applications
consuming Oak via the JCR API ( obviously ) or via the Oak API (
ContentRepository / ContentSession / Tree etc ).

There can be changes to applications hooking into Oak's SPIs, for
instance Sling which sets up an Oak content repository instance via
OSGi.

So in my view most consumers will not be affected.

> 
> If so, the follow-up question is, do we have plans to retain backward
> API
> compatibility between 1.6 and 1.8 such that any current code relying
> on 1.6
> API will continue to work with the 1.8 release?
> 
> If backward compatibility is in the plan let's make sure it is
> identified
> in the plan; so far I haven't noticed this but surely I could have
> missed
> it.

When we first approached the m12n task we decided to first make it work
as it should. I am not sure with the scale of changes that we
can/should offer backwards compatibility. I'd rather adapt a 'wait and
see' approach, and handle each case individually. There may be just a
small number of backwards compatible shims we need provide, rather than
making everything backwards compatible.

Instead, I view this as an opportunity to really make things backwards
compatible from now on :-)

> 
> If backward compatibility is not in the plan, the next question I ask
> is
> whether the next release should actually be Oak 2.0 instead of Oak
> 1.8?  If
> semantic versioning matters it seems to me this change would qualify
> for a
> major release bump.

In my view the Oak version is a 'marketing' version, denoting stability
and feature increments, rather than backwards compatibility to
implementors.

I think that packages should be semantically versioned and - even more
- that modules should be independently versioned. With that, the Oak
version would become even less relevant to these changes.

Thanks,

Robert

> 
> 
> My intent isn't as much to lobby for strict adherence to semantic
> versioning so much as to make sure we are mindful of what appears to
> be a
> change in the public API contract and that we have a plan to manage
> it.
> 
> 
> -MR
> 
> 
> On Thu, Apr 13, 2017 at 7:52 AM, Angela Schreiber 
> wrote:
> 
> > 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"  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
> > > > ata=02%7C01%7C%7Cd062470b1185427e793608d48256
> > 
> > 5535%7Cfa7b1b5a7b34438794aed
> > > > 2c178decee1%7C0%7C0%7C636276754686224956=
> > 
> > W7sTOFt4hmoew%2BMR7K%2F45I
> > > > PvOAOSQPsaGKhWfMUWOuI%3D=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