[ https://issues.apache.org/jira/browse/OAK-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861083#comment-16861083 ]
Julian Reschke commented on OAK-8339: ------------------------------------- I agree that we shouldn't do both at the same time. The reason why I mentioned it was because it might be considered good if Oak didn't have any Jackrabbit dependencies anymore (the other one would be -data). > Move jackrabbit-api project into Oak > ------------------------------------ > > Key: OAK-8339 > URL: https://issues.apache.org/jira/browse/OAK-8339 > Project: Jackrabbit Oak > Issue Type: Task > Reporter: Julian Reschke > Assignee: Julian Reschke > Priority: Major > Fix For: 1.16.0 > > > {{jackrabbit-api}} contains extensions over the base JCR API. Although most > work happens in Oak, it still is a subproject of classic Jackrabbit. This > complicates evolution, because we need a stable release of Jackrabbit before > we can implement new/changed APIs in Oak. > Going forward, we should however try to break this dependency. This will > eliminate the top reason why we have been branching Jackrabbit in the past. > To do that, the following should work: > - (svn) cp the subproject over to Oak (oak-jackrabbit-api), align the POM, > but do not touch > package name or export versions > - in Oak, use the new artefact instead of jackrabbit-api > - once a new stable Oak is released (1.16, sometime later this year), > drop the jackrabbit-api subproject in Jackrabit, and inside the other > Jackrabbit > subprojects reference oak-jackrabbit-api instead > - we probably should try to generate a "tombstone" release of > jackrabbit-api, that would point people to the changed location (needs > research...) before entirely removing the subproject -- This message was sent by Atlassian JIRA (v7.6.3#76005)