Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-3300

tests should consistently check for repository support and fail with NotExecutableException when the repo does not support the feature

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.4.1, 2.6
    • Fix Version/s: 2.4.2, 2.5
    • Component/s: jackrabbit-jcr-tests
    • Labels:
      None

      Description

      AbstractVersionTest should check for Repository.OPTION_VERSIONING_SUPPORTED and throw NotExecutableException when not set

      RSessionAccessControlTest needs to extend from AbstractAccessControlTest instead of AbstractJCRTest

      etc.

        Activity

        Hide
        Julian Reschke added a comment -

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

        Show
        Julian Reschke added a comment - there are a few more missing checks, and some tests that extend the wrong variant of AbstractVersionTest
        Hide
        Julian Reschke added a comment -

        similar issue for some access control tests

        Show
        Julian Reschke added a comment - similar issue for some access control tests
        Hide
        Randall Hauch added a comment -

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

        Show
        Randall Hauch added a comment - Any chance this could be backported to be included in 2.4.2, as JCR-3307 has been?
        Hide
        Julian Reschke added a comment -

        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?

        Show
        Julian Reschke added a comment - 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?
        Hide
        Randall Hauch added a comment -

        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.

        Show
        Randall Hauch added a comment - 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.
        Hide
        Julian Reschke added a comment -

        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?

        Show
        Julian Reschke added a comment - 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?
        Hide
        Randall Hauch added a comment -

        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!

        Show
        Randall Hauch added a comment - 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!
        Hide
        Jukka Zitting added a comment -

        > 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?

        Show
        Jukka Zitting added a comment - > 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?
        Hide
        Randall Hauch added a comment -

        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?

        Show
        Randall Hauch added a comment - 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?

          People

          • Assignee:
            Julian Reschke
            Reporter:
            Julian Reschke
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development