You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Robert Munteanu <ro...@apache.org> on 2017/04/06 14:41:16 UTC

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

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://github.com/mreutegg/jackrabbit-oak/tree/m12n

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

Posted by Angela Schreiber <an...@adobe.com>.
I create OAK-6092 <https://issues.apache.org/jira/browse/OAK-6092> to
track the relocation of ApproximateCounter.

regards
angela

On 18/04/17 10:39, "Michael Dürig" <md...@apache.org> wrote:

>
>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" <ro...@apache.org> 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%7C287ecd3d73524
>>>6c
>>> 
>>>cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636277636
>>>78
>>> 
>>>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" <ro...@apache.org> 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
>>>>
>>>>
>>>
>>


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

Posted by Michael Dürig <md...@apache.org>.
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" <ro...@apache.org> 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" <ro...@apache.org> 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
>>>
>>>
>>
>

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

Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-04-19 at 15:53 +0000, Angela Schreiber wrote:
> hi robert
> 
> i created 2 separate tasks in the OAK-6069 m12n epic to track
> progress
> with ApproximateCounter and NodeUtil|TreeUtil respectively.
> moving the ApproximateCounter should be doable with limited effort,
> we
> just need to get a better understanding if that is/will/shouldbe used
> more
> widely than just for the indexing.

I've commented on OAK-6093 - I think we should start with getting the
naming right.

Robert

> 
> the other one probably needs some more effort.
> angela�
> 
> 
> On 19/04/17 17:45, "Robert Munteanu" <ro...@apache.org> wrote:
> 
> > On Tue, 2017-04-18 at 06:21 +0000, 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?
> > 
> > (Sorry, missed this somehow)
> > 
> > Yes, holding on for now sounds good to me.
> > 
> > Thanks,
> > 
> > Robert
> > 
> > > 
> > > Kind regards
> > > Angela
> > > 
> > > 
> > > On 14/04/17 12:47, "Robert Munteanu" <ro...@apache.org> 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%
> > > > 2Fgi
> > > > thub.co
> > > > m%2Fmreutegg%2Fjackrabbit-
> > > > oak%2Fpull%2F6&data=02%7C01%7C%7C287ecd3d735246c
> > > > cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
> > > > 6362
> > > > 7763678
> > > > 7796080&sdata=HSDWauCHB%2Bb4OaX90CfEWsA7487EP3FvrSicZNgKD8Q%3D&
> > > > rese
> > > > rved=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" <ro...@apache.org>
> > > > > 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%2B1svSP0kvlkLMksm
> > > > > > WcM%
> > > > > > 3D&r
> > > > > > eserved
> > > > > > =0
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 


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

Posted by Angela Schreiber <an...@adobe.com>.
hi robert

i created 2 separate tasks in the OAK-6069 m12n epic to track progress
with ApproximateCounter and NodeUtil|TreeUtil respectively.
moving the ApproximateCounter should be doable with limited effort, we
just need to get a better understanding if that is/will/shouldbe used more
widely than just for the indexing.

the other one probably needs some more effort.
angela 


On 19/04/17 17:45, "Robert Munteanu" <ro...@apache.org> wrote:

>On Tue, 2017-04-18 at 06:21 +0000, 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?
>
>(Sorry, missed this somehow)
>
>Yes, holding on for now sounds good to me.
>
>Thanks,
>
>Robert
>
>> 
>> Kind regards
>> Angela
>> 
>> 
>> On 14/04/17 12:47, "Robert Munteanu" <ro...@apache.org> 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%2Fgi
>> > thub.co
>> > m%2Fmreutegg%2Fjackrabbit-
>> > oak%2Fpull%2F6&data=02%7C01%7C%7C287ecd3d735246c
>> > cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6362
>> > 7763678
>> > 7796080&sdata=HSDWauCHB%2Bb4OaX90CfEWsA7487EP3FvrSicZNgKD8Q%3D&rese
>> > rved=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" <ro...@apache.org> 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
>> > > 
>> > > 
>> 
>> 
>


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

Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-04-18 at 06:21 +0000, 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?

(Sorry, missed this somehow)

Yes, holding on for now sounds good to me.

Thanks,

Robert

> 
> Kind regards
> Angela
> 
> 
> On 14/04/17 12:47, "Robert Munteanu" <ro...@apache.org> 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%2Fgi
> > thub.co
> > m%2Fmreutegg%2Fjackrabbit-
> > oak%2Fpull%2F6&data=02%7C01%7C%7C287ecd3d735246c
> > cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6362
> > 7763678
> > 7796080&sdata=HSDWauCHB%2Bb4OaX90CfEWsA7487EP3FvrSicZNgKD8Q%3D&rese
> > rved=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" <ro...@apache.org> 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
> > > 
> > > 
> 
> 


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

Posted by Angela Schreiber <an...@adobe.com>.
see also OAK-6093 <https://issues.apache.org/jira/browse/OAK-6093> for the
corresponding JIRA ticket to make sure we consider that as part of the
modularisation epic

kind regards
angela

On 18/04/17 08:21, "Angela Schreiber" <an...@adobe.com> 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" <ro...@apache.org> 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.c
>>o
>>m%2Fmreutegg%2Fjackrabbit-oak%2Fpull%2F6&data=02%7C01%7C%7C287ecd3d735246
>>c
>>cbc8308d48323b62e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6362776367
>>8
>>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" <ro...@apache.org> 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
>>> 
>>> 
>>
>


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

Posted by Angela Schreiber <an...@adobe.com>.
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" <ro...@apache.org> 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" <ro...@apache.org> 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
>> 
>> 
>


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

Posted by Robert Munteanu <ro...@apache.org>.
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 +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" <ro...@apache.org> 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
> 
> 


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

Posted by Angela Schreiber <an...@adobe.com>.
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" <ro...@apache.org> 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%2Fgithub.co
>m%2Fmreutegg%2Fjackrabbit-oak%2Ftree%2Fm12n&data=02%7C01%7C%7Cbfc1feb5ff4a
>4866c79c08d47cfafe6d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627086
>4841267177&sdata=CWwq4ifTZIU1gW9UEd2STRLm%2B1svSP0kvlkLMksmWcM%3D&reserved
>=0