I just had to test some code that uses the SlingRepository. Initially I wanted to test against Oak 1.7 or 1.8 but I found that org.apache.sling.jcr.oak.server is compiled against Oak 1.6 and does not run with Oak 1.7 or 1.8.
So what is the timeline for Oak 1.8 support in sling? Does it make to start on this already? I looked into the differences and found these incompatible changes regarding the osk.server module : 1.6 import org.apache.jackrabbit.oak.plugins.index.aggregate.NodeAggregator; import org.apache.jackrabbit.oak.plugins.nodetype.write.InitialContent; import org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider; import org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexProvider; all located on oak-core 1.7 import org.apache.jackrabbit.oak.spi.query.QueryIndex.NodeAggregator; -> oak-query-spi import org.apache.jackrabbit.oak.InitialContent; -> oak-core import org.apache.jackrabbit.oak.spi.query.WhiteboardIndexProvider; -> oak-query-spi import org.apache.jackrabbit.oak.plugins.index.WhiteboardIndexEditorProvider; -> oak-core So ideally Oak would provide a compatiblity support in 1.8 to not break clients at the moment and provide a smooth transition but I am not sure if that is an option. I will check on the Oak list about that. For sling I could move the org.apache.sling.jcr.oak.server to Oak 1.7 / 1.8 (I hope we can support both). Does it make sense to already do this now on master or better on a branch? As I am no comitter I will do a PR anyway of course .. Btw. One other thing I observed is that org.apache.sling.jcr.oak.server resolves in OSGi with Oak 1.7 but then fails at runtime as it can not find NodeAggregator. So one other thing we should aim for is to make sure OSGi gives an error at resolve time if the Oak version does not work for the sling bundle. Best Christian -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
