there are a few more missing checks, and some tests that extend the wrong variant of AbstractVersionTest

similar issue for some access control tests

Any chance this could be backported to be included in 2.4.2, as JCR-3307 has been?

Any chance this could be backported to be included in 2.4.2, as JCR-3307 has been?

We could but I'm not sure why. Can you explain why you need it backported?

Well, we don't need it back ported, but we'd prefer it. Of course, it really depends on the timing of the 2.4.2 release versus the 2.6 release. If they happen at nearly the same time, then 2.6 is fine.

The reason I asked is that several of the recently reported TCK issues (JCR-2662, JCR-3307) have already been (recently) applied to the 2.4 branch, so I was simply hoping that this issue (JCR-3300), JCR-3313 and JCR-2666 can similarly be applied. I think all three deal with either relaxing some of the asserts that are too strict or not running tests based upon repository descriptors, and thus shouldn't affect Jackrabbit's success in passing the TCK, even on the 2.4 branch.

Randall, the reason I ask is because I'd like to avoid blindly porting back things that aren't needed. If we did that, we wouldn't need trunk, right?

The only reason I can think of for backporting TCK fixes is because somebody tries to run the TCK against something where the tests fail due to the test problem, which seems to imply running against something which is not Jackrabbit in the first place. That's of course fine (that's why we have a TCK), but then why can't you simply run the tests from trunk?

Julian, I completely understand the desire to limit back ports, but TCK fixes are a bit of a different story IMO.

We are running the TCK tests against something that is not Jackrabbit. ModeShape is another JCR implementation, and we're currently using version 2.4.1 of the TCK tests on several different versions of ModeShape. We actually do have features that are written per the specification that are failing several TCK tests because of bugs in the TCK tests themselves. Running the TCK in trunk is not feasible for our Maven builds, and IIUC Jackrabbit doesn't publish SNAPSHOT into a Maven repository. So we're limited to selecting from the Jackrabbit releases.

Again, if the 2.6 release timeframe is about the same as 2.4.2, then we probably can wait for 2.6. If 2.6 is going to be a bit, we really would love to have these issues fixed in 2.4.2.

We really do appreciate the additional work on fixing these issues! Many thanks!

> We actually do have features that are written per the specification that are failing
> several TCK tests because of bugs in the TCK tests themselves.

Do you have fixes for those test cases? It would be great to have them in jackrabbit-jcr-tests so that they can be easily incorporated to JSR 333.

> If 2.6 is going to be a bit, we really would love to have these issues fixed in 2.4.2.

There's no immediate plan for 2.6, but I was thinking of cutting an unstable 2.5.0 release from trunk within the next few days. Will that work for you?

Thanks, Jukka. We do have (suggested) fixes for the test cases: see the patch attached to JCR-3313, and I hope later today I can attach a patch for JCR-2666.

A new unstable 2.5.0 release should work fine. I guess the stability of the releases doesn't really apply to the TCK test artifact. Does that mean 2.4.2 is not going to happen? We don't need the release immediately, and would be happy with a release anytime during the next few weeks. We've been logging issues as soon as we find them, but with our 3.0 effort approaching Beta we'd like our TCK tests to run cleanly and successfully. So we're trying to help resolve the outstanding issues (JCR-2666 was logged almost 2 years ago).

Perhaps this is not the best place to ask, but has there ever been any discussion about separating the TCK tests into a separate project, with it's own release cycle?