Hi, > For maximum backward compatibility and minimal impact on future > requirements re. JCR 2.1 I suggest we implement the new APIs (at least > as stubs) in order to avoid potential collisions.
+1 makes sense. > Where required we could expose those implementations through the Oak > API, which would then later on overlap the JCR 2.1 API. do you mean JCR interface extensions in Oak or the actual Oak API in oak-core? I wouldn't do the first now for the same reasons you stated about creating a dependency to the JCR 2.1. API. the spec is not yet final. the latter may be OK since the methods are in a different layer anyway. regards marcel
