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
On 2.12.13 9:06 , Marcel Reutegger wrote:
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
Hi,
This question has already come up on OAK-190 [1]: how should we proceed
wrt. the upcoming JCR 2.1 specification [2]?
JSR-333 is Proposed Final Draft, which means that it is waiting on the
completion of the RI and TCK. However, it seem Oak 1.0 will arrive
sooner than the final JSR-333
