AFAIK ApproximateCounter was intended to be general purpose. So moving
it close to indexing would not be the right thing. We probably need to
involve Thomas here to provide his perspective.
But then, I think this (and as well as the considerations around
NodeUtil and TreeUtil) should be tackled separately.
Michael
On 18.04.17 08:21, Angela Schreiber wrote:
Hi Robert
While NodeUtil and TreeUtil would naturally fit to plugins.tree, I am not
convinced that ApproximateCounter really belongs there. Afaik it is only
used for query index strategy and counting. I would rather move
'ApproximateCounter' to 'plugins.index'.
Regarding moving 'NodeUtil' and 'TreeUtil': IMHO we have here 2 utility
classes providing almost the same functionality. I would prefer to decide
on the redundancy (and potentially clean it up) before moving it to a
package that already has semantic versioning enabled (in contrast to the
util package where they currently are located).
wdyt?
Kind regards
Angela
On 14/04/17 12:47, "Robert Munteanu" <[email protected]> wrote:
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fmreutegg%2Fjackrabbit-oak%2Fpull%2F6&data=02%7C01%7C%7C287ecd3d735246c
cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627763678
7796080&sdata=HSDWauCHB%2Bb4OaX90CfEWsA7487EP3FvrSicZNgKD8Q%3D&reserved=0
Robert
On Thu, 2017-04-06 at 14:49 +0000, 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" <[email protected]> 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&data=02%7C01%7C%7Cbfc1feb5ff4a
4866c79c08d47cfafe6d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
3627086
4841267177&sdata=CWwq4ifTZIU1gW9UEd2STRLm%2B1svSP0kvlkLMksmWcM%3D&r
eserved
=0
