jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Hauch <rha...@gmail.com>
Subject Re: JSR-283 official TCK and the 'jackrabbit-jcr-tests'
Date Fri, 03 Aug 2012 15:21:26 GMT
Hi, Julian:

I agree that the TCK unit tests are in really good shape, especially given that all of our
known issues with them will be addressed in the 2.5.1 release (see [1]). Separating the TCK
unit tests with its own independent release cycle will definitely require some up front work,
and whether this work will be worth it may depend on several things:

* Relationship to the official TCK

The Jackrabbit TCK page [2] states that Jackrabbit's JCR Tests module is used within the official
JSR-283 TCK [3] but is not the official TCK test. Obviously the former have been maintained
and continue to improve, but the official JSR-283 TCK tests appear to have been released last
on August 19, 2009. Is it possible that the official JSR-283 TCK tests can be updated, and
would having a separate release schedule help with this in any way? (If the official TCK tests
cannot be updated, then I presume any project wanting to claim JSR-283 compliance would have
to run the official TCKs and appeal each of the older incorrect tests by stating the issue
and perhaps using the updated/corrected tests Jackrabbit JCR Tests module as "corrections".
Is there anything that makes this easier with a non-updated TCK? How does Jackrabbit show
spec and TCK compliance?)

* New tests

The official TCK and Jackrabbit's JCR tests unsurprisingly do not completely cover the specification,
and doing so would require a significant amount of effort. However, there may be opportunity
over time for projects to propose adding new tests. If the JCR Tests' release cycle were independent
from the Jackrabbit's release cycle, then the process of adding new tests and releasing updated
JCR tests might be easier. On the other hand, verification that the tests are valid may become
a bit harder. (We'd probably want to define a process to govern such additions and whether
they are valid. At the moment, the )

For example, the ModeShape project has around 70 additional tests [4] that we'd be willing
to donate. Most of these are around verifying administration privileges (e.g., registering
namespaces, node types, etc., especially for anonymous users), versioning, and locking. Obviously
we'd do this by submitting a proposed patch for the appropriate JCR unit test cases, and we'd
want others to verify the expectations are indeed mandated in the specification. (Any Jackrabbit
failures of the proposed tests might be a signal the tests.

Additionally, the Oak effort is already running the JCR tests and has recently found/fixed
issues, too. Can those participating in Oak offer how much they might expect to simply reuse
vs. add new tests?


Best regards,

Randall Hauch
Project lead, ModeShape

[1] http://markmail.org/thread/isihzvirvrc4idpp
[2] http://jackrabbit.apache.org/jackrabbit-jcr-tests.html
[3] http://www.day.com/day/en/products/jcr/jsr-283.html
[4] https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test/java/org/modeshape/jcr/ModeShapeTckTest.java


On Thursday, June 7, 2012 at 11:58 AM, Julian Reschke wrote:

> On 2012-06-07 18:19, Michael Dürig wrote:
> > Hi Randall,
> >  
> > I think forking of the jcr-test module into its own release cycle
> > definitely makes sense. The easiest thing would be to just make it a
> > sub-project of Jackrabbit and move it from trunk/jackrabbit-jcr-tests to
> > jcr-tests/trunk. In addition we'd probably also need a separate issued
> > tracker and migrate existing issues.
> >  
> > However, this comes with some additional effort and complexity. Apart
> > from the initial move and fixing of existing dependencies we'd need a
> > release manager who takes care of the new sub-project. Not sure whether
> > Alex has enough cylces left to take this over.
> >  
> > Let's see what others think of this and then open an issue from the
> > conclusion.
> >  
> > Michael
> > ...
> >  
>  
>  
> I agree that decoupling is the right thing to do. On the other hand,  
> decoupling also requires (a) some initial work, and (b) ongoing work to  
> actually cut the separate releases.
>  
> It seems that the original problem that triggered this discussion was  
> the amount of changes in trunk that were not present in a non-SNAPSHOT  
> release. In the meantime, 2.5.0 *has* been released, and looking at the  
> Jackrabbit release history, we've made releases every few months.
>  
> So is the trouble really worth it? Who volunteers to take case of this?
>  
> Best regards, Julian  


Mime
View raw message