[
https://issues.apache.org/jira/browse/OAK-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042472#comment-16042472
]
angela edited comment on OAK-6304 at 6/8/17 11:52 AM:
------------------------------------------------------
[~tmueller], surprisingly the _oak.query.ast_ package is only used in
test-cases outside of _oak-core_. do you remember why it was exported in the
first place? Removing the export statement for _oak.query.ast_ moves the
warning to the index package:
{code}
[WARNING] Bundle org.apache.jackrabbit:oak-core:bundle:1.8-SNAPSHOT : Export
org.apache.jackrabbit.oak.query.index, has 1, private references
[org.apache.jackrabbit.oak.query.ast]
{code}
These usages are as follows:
* {{org.apache.jackrabbit.oak.query.index.TraversingIndex}}: only references
{{org.apache.jackrabbit.oak.query.ast.JoinConditionImpl#SPECIAL_PATH_PREFIX}}:
this constant is actually only used inside
_org.apache.jackrabbit.oak.query.index_ -> could be fixed with moderate effort.
* {{org.apache.jackrabbit.oak.query.index.FilterImpl}}: this one is a bit
trickier:
** {{org.apache.jackrabbit.oak.query.ast.JoinConditionImpl}} -> see above, easy
** {{org.apache.jackrabbit.oak.query.ast.NativeFunctionImpl}}: referencing
{{NATIVE_PREFIX}} constant => should be easy as well.
** {{org.apache.jackrabbit.oak.query.ast.Operator}}: there are 2 public methods
(not part of the {{Filter}} interface declaration) that have the {{Operator}}
as param. Would it be worth to consider moving the {{Operator}} to an spi
package and include the 2 methods in the API contract of {{FilterImpl}}? Or was
it sufficient to move {{Operator}} from the _ast_ package to _query.index_
(afaik it's only used there)?
** {{org.apache.jackrabbit.oak.query.ast.SelectorImpl}}: this is the "nasty"
one as it is a param of the {{FilterImpl}} constructor and used the public
method {{getSelector}} that is not part of the {{Filter}} API contract.
[~tmueller], any idea/hint? Ouhm... extracting a {{Selector}} interface would
actually do the trick for everything _except_ {{SelectorImpl.getQuery}}, which
is used only inside {{FilterImpl}} to calculate {{Filter.isAccessible}} though
access to {{PermissionProvider}} held in the {{ExecutionContext}}... that looks
a bit odd.
was (Author: anchela):
[~tmueller], surprisingly the _oak.query.ast_ package is only used in
test-cases outside of _oak-core_. do you remember why it was exported in the
first place? Removing the export statement for _oak.query.ast_ moves the
warning to the index package:
{code}
[WARNING] Bundle org.apache.jackrabbit:oak-core:bundle:1.8-SNAPSHOT : Export
org.apache.jackrabbit.oak.query.index, has 1, private references
[org.apache.jackrabbit.oak.query.ast]
{code}
These usages are as follows:
* {{org.apache.jackrabbit.oak.query.index.TraversingIndex}}: only references
{{org.apache.jackrabbit.oak.query.ast.JoinConditionImpl#SPECIAL_PATH_PREFIX}}:
this constant is actually only used inside
_org.apache.jackrabbit.oak.query.index_ -> could be fixed with moderate effort.
* {{org.apache.jackrabbit.oak.query.index.FilterImpl}}: this one is a bit
trickier:
** {{org.apache.jackrabbit.oak.query.ast.JoinConditionImpl}} -> see above, easy
** {{org.apache.jackrabbit.oak.query.ast.NativeFunctionImpl}}: referencing
{{NATIVE_PREFIX}} constant => should be easy as well.
** {{org.apache.jackrabbit.oak.query.ast.Operator}}: there are 2 public methods
(not part of the {{Filter}} interface declaration) that have the {{Operator}}
as param. Would it be worth to consider moving the {{Operator}} to an spi
package and include the 2 methods in the API contract of {{FilterImpl}}? Or was
it sufficient to move {{Operator}} from the _ast_ package to _query.index_
(afaik it's only used there)?
** {{org.apache.jackrabbit.oak.query.ast.SelectorImpl}}: this is the "nasty"
one as it is a param of the {{FilterImpl}} constructor and used the public
method {{getSelector}} that is not part of the {{Filter}} API contract.
[~tmueller], any idea/hint?
> Cyclic dependency between oak.spi.query an oak.query.*
> ------------------------------------------------------
>
> Key: OAK-6304
> URL: https://issues.apache.org/jira/browse/OAK-6304
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, indexing, query
> Reporter: angela
> Attachments: OAK-6304.patch, OAK-6304-test.patch
>
>
> while working on OAK-6069 i noticed that there exist IMO troublesome
> dependencies from _o.a.j.oak.spi.query_ back to _o.a.j.oak.query.*_. While i
> don't know the historical reasons that led to this setup it feels wrong to me
> that the interfaces and classes in _o.a.j.oak.spi.query_ would have
> dependencies to packages that from my understanding are supposed to contain
> implementations.
> while utilities like {{o.a.j.oak.spi.query.Cursors}} may simply have ended up
> in the wrong bucket and could possibly moved to e.g _o.a.j.query.index_, i
> couldn't find an easy solution for an interface like
> {{o.a.j.oak.spi.query.Filter}} that defines methods returning
> {{o.a.j.query.fulltext.FullTextExpression}} and
> {{o.a.j.query.QueryEngineSettings}}, while at the same time being tied to the
> {{o.a.j.oak.spi.query.QueryIndex}} interface.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
