[jira] Commented: (JCR-2692) Split jcr-commons in two
[
https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895234#action_12895234
]
Michael Dürig commented on JCR-2692:
The idea using a released version of jackrabbit-core for testing does not work:
org.apache.jackrabbit
jackrabbit-core
2.0.0
test
still results in
[INFO] The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='org.apache.jackrabbit:jackrabbit-core'}' and
'Vertex{label='org.apache.jackrabbit:jackrabbit-jcr-commons'}' introduces to
cycle in the graph org.apache.jackrabbit:jackrabbit-jcr-commons -->
org.apache.jackrabbit:jackrabbit-core -->
org.apache.jackrabbit:jackrabbit-jcr-commons
> Split jcr-commons in two
> -
>
> Key: JCR-2692
> URL: https://issues.apache.org/jira/browse/JCR-2692
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.2.0
>Reporter: Michael Dürig
>
> As discussed in JCR-2688, the jcr commons module should be split:
> * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR
> * jcr-api-commons - utility classes/interfaces for help *using* JCR
> The rational is that it contains utility classes for jackrabbit-core on one
> hand and utility classes for JCR API consumers on the other hand. Currently
> there is no clean way to add unit tests for JCR API utility classes since
> this would introduce a circular dependency on jackrabbit-core. Such unit
> tests currently live in the jackrabbit-core module in the
> o.a.j.core.integration package. Along with the split these tests should be
> considered to be moved to the jcr-api-commons module.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2692) Split jcr-commons in two
[ https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895039#action_12895039 ] Alexander Klimetschek commented on JCR-2692: spi-commons is probably a good target for the implementation helper classes, as it seems to be a jcr-impl-helper library already. But its name could need some adjustment then ;-) Otherwise Jukka's quick solution is probably good for now, since this split-up is most likely a little bit of work. > Split jcr-commons in two > - > > Key: JCR-2692 > URL: https://issues.apache.org/jira/browse/JCR-2692 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Affects Versions: 2.2.0 >Reporter: Michael Dürig > > As discussed in JCR-2688, the jcr commons module should be split: > * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR > * jcr-api-commons - utility classes/interfaces for help *using* JCR > The rational is that it contains utility classes for jackrabbit-core on one > hand and utility classes for JCR API consumers on the other hand. Currently > there is no clean way to add unit tests for JCR API utility classes since > this would introduce a circular dependency on jackrabbit-core. Such unit > tests currently live in the jackrabbit-core module in the > o.a.j.core.integration package. Along with the split these tests should be > considered to be moved to the jcr-api-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2692) Split jcr-commons in two
[ https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895009#action_12895009 ] Tobias Bocanegra commented on JCR-2692: --- can you please provide details there what class would move? can't we move all the "core-support" stuff to spi-commons? otherwise: i support jukka's idea to use a released version of jackrabbit-core for testing, > Split jcr-commons in two > - > > Key: JCR-2692 > URL: https://issues.apache.org/jira/browse/JCR-2692 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Affects Versions: 2.2.0 >Reporter: Michael Dürig > > As discussed in JCR-2688, the jcr commons module should be split: > * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR > * jcr-api-commons - utility classes/interfaces for help *using* JCR > The rational is that it contains utility classes for jackrabbit-core on one > hand and utility classes for JCR API consumers on the other hand. Currently > there is no clean way to add unit tests for JCR API utility classes since > this would introduce a circular dependency on jackrabbit-core. Such unit > tests currently live in the jackrabbit-core module in the > o.a.j.core.integration package. Along with the split these tests should be > considered to be moved to the jcr-api-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2692) Split jcr-commons in two
[ https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894856#action_12894856 ] Jukka Zitting commented on JCR-2692: See my comment in JCR-2688 for a way to avoid the circular dependency. That should solve the problem with unit tests, thus removing the above rationale for splitting the jcr-commons component. > Split jcr-commons in two > - > > Key: JCR-2692 > URL: https://issues.apache.org/jira/browse/JCR-2692 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Affects Versions: 2.2.0 >Reporter: Michael Dürig > > As discussed in JCR-2688, the jcr commons module should be split: > * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR > * jcr-api-commons - utility classes/interfaces for help *using* JCR > The rational is that it contains utility classes for jackrabbit-core on one > hand and utility classes for JCR API consumers on the other hand. Currently > there is no clean way to add unit tests for JCR API utility classes since > this would introduce a circular dependency on jackrabbit-core. Such unit > tests currently live in the jackrabbit-core module in the > o.a.j.core.integration package. Along with the split these tests should be > considered to be moved to the jcr-api-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2692) Split jcr-commons in two
[ https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894848#action_12894848 ] Felix Meschberger commented on JCR-2692: +1 to splitting +1 to moving the tests out of jackrabbit-core (of course ;-) ) I would suggest to rethink the naming, though. How about jcr-util for the developper/user oriented part jcr-core-supportfor the part used by jackrabbit-core (and presumably others implementing JCR API) > Split jcr-commons in two > - > > Key: JCR-2692 > URL: https://issues.apache.org/jira/browse/JCR-2692 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Affects Versions: 2.2.0 >Reporter: Michael Dürig > > As discussed in JCR-2688, the jcr commons module should be split: > * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR > * jcr-api-commons - utility classes/interfaces for help *using* JCR > The rational is that it contains utility classes for jackrabbit-core on one > hand and utility classes for JCR API consumers on the other hand. Currently > there is no clean way to add unit tests for JCR API utility classes since > this would introduce a circular dependency on jackrabbit-core. Such unit > tests currently live in the jackrabbit-core module in the > o.a.j.core.integration package. Along with the split these tests should be > considered to be moved to the jcr-api-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
