Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.1
    • Component/s: jcr
    • Labels:

      Description

      One of the proposed goals for the 0.1 release is at least a basic JCR binding for Oak. Most of that already exists in /jackrabbit/sandbox, we just need to decide where and how to place it in Oak. I think we should either put it all under o.a.j.oak.jcr in oak-core, or create a separate oak-jcr component for the JCR binding.

      As for functionality, it would be nice if the JCR binding was able to do at least the following:

      Repository repository = JcrUtils.getRepository(...);
      
      Session session = repository.login(...);
      try {
          // Create
          session.getRootNode().addNode("hello")
              .setProperty("world",  "hello world");
          session.save();
      
          // Read
          assertEquals(
              "hello world",
              session.getProperty("/hello/world").getString());
      
          // Update
          session.getNode("/hello").setProperty("world", "Hello, World!");
          session.save();
          assertEquals(
              "Hello, World!",
              session.getProperty("/hello/world").getString());
      
          // Delete
          session.getNode("/hello").delete();
          session.save();
          assertTrue(!session.propertyExists("/hello/world"));
      } finally {
          create.logout();
      }
      

        Issue Links

          Activity

          Hide
          Dominique Pfister added a comment -

          > I think we should either put it all under o.a.j.oak.jcr in oak-core,
          > or create a separate oak-jcr component for the JCR binding.

          I'm in favor of a separate component, because oak-core already contains quite some packages
          and classes (and this separation would also underline the different layers), but I wouldn't mind a separate package either.

          Show
          Dominique Pfister added a comment - > I think we should either put it all under o.a.j.oak.jcr in oak-core, > or create a separate oak-jcr component for the JCR binding. I'm in favor of a separate component, because oak-core already contains quite some packages and classes (and this separation would also underline the different layers), but I wouldn't mind a separate package either.
          Hide
          Thomas Mueller added a comment -

          I would like to keep both in the same project currently. Of course we need to use separate packages.

          As an example for the query/index component, a part of the code (the QOM/AST) is currently useful for both the core and the JCR binding. At some point it will have to be separated, but I think it would simplify development a lot if we could keep it together for now.

          Show
          Thomas Mueller added a comment - I would like to keep both in the same project currently. Of course we need to use separate packages. As an example for the query/index component, a part of the code (the QOM/AST) is currently useful for both the core and the JCR binding. At some point it will have to be separated, but I think it would simplify development a lot if we could keep it together for now.
          Hide
          Stefan Guggisberg added a comment -

          > I think we should either put it all under o.a.j.oak.jcr in oak-core,
          > or create a separate oak-jcr component for the JCR binding.

          +1 for a separate component.

          i guess we should have at least 3 components, reflecting
          the 3 layers (jcr/transient space, spi, mk).

          Show
          Stefan Guggisberg added a comment - > I think we should either put it all under o.a.j.oak.jcr in oak-core, > or create a separate oak-jcr component for the JCR binding. +1 for a separate component. i guess we should have at least 3 components, reflecting the 3 layers (jcr/transient space, spi, mk).
          Hide
          Thomas Mueller added a comment -

          +1 for separate components in the future, but

          -1 for separate components at the moment,
          to simplify development until things get stable

          What are the advantages of having separate components now?

          Show
          Thomas Mueller added a comment - +1 for separate components in the future, but -1 for separate components at the moment, to simplify development until things get stable What are the advantages of having separate components now?
          Hide
          Michael Dürig added a comment -

          The sandbox currently contains two JCR implementations [1, 2] on top of the Microkernel. Both implementations are results from experimenting with implementation approaches [3]. [2] is based on a hacked SPI stack and brings along a lot of further dependencies and lot of legacy. [1] is a fresh implementation from scratch. Apart from using JcrUtils for acquiring the repository, both implementations pass above test.

          From my experience while working on these implementations I suggest we go with [1] and selectively copy things over from existing libraries (i.e. spi-commons, jcr-commons, ...) as we go.

          [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/
          [2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/
          [3] https://docs.google.com/presentation/pub?id=1wGoisT6xog9wZi9IfH1rGt-HyiytFNCR3UuD9zd-IK4&start=false&loop=false&delayms=3000#slide=id.p

          Show
          Michael Dürig added a comment - The sandbox currently contains two JCR implementations [1, 2] on top of the Microkernel. Both implementations are results from experimenting with implementation approaches [3] . [2] is based on a hacked SPI stack and brings along a lot of further dependencies and lot of legacy. [1] is a fresh implementation from scratch. Apart from using JcrUtils for acquiring the repository, both implementations pass above test. From my experience while working on these implementations I suggest we go with [1] and selectively copy things over from existing libraries (i.e. spi-commons, jcr-commons, ...) as we go. [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/ [2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/ [3] https://docs.google.com/presentation/pub?id=1wGoisT6xog9wZi9IfH1rGt-HyiytFNCR3UuD9zd-IK4&start=false&loop=false&delayms=3000#slide=id.p
          Hide
          Stefan Guggisberg added a comment -

          > What are the advantages of having separate components now?

          a clean project structure and separation of concerns, as reflected
          by the mk and spi abstractions.

          another advantage is to have smaller, clearly laid out package
          structures instead of just one single confusing overloaded source tree.

          Show
          Stefan Guggisberg added a comment - > What are the advantages of having separate components now? a clean project structure and separation of concerns, as reflected by the mk and spi abstractions. another advantage is to have smaller, clearly laid out package structures instead of just one single confusing overloaded source tree.
          Hide
          angela added a comment -

          i'd like to second the arguments provided by stefan with respect
          the separate components for JCR + transient space, SPI and mk.

          if we don't separate them now we will no be able to separate
          them later on and will end up with odd situations where the
          layers are not properly separated... keeping the code in
          separate components is IMO helpful and forces us to take
          conscious decisions regarding what to put where.

          Show
          angela added a comment - i'd like to second the arguments provided by stefan with respect the separate components for JCR + transient space, SPI and mk. if we don't separate them now we will no be able to separate them later on and will end up with odd situations where the layers are not properly separated... keeping the code in separate components is IMO helpful and forces us to take conscious decisions regarding what to put where.
          Hide
          Thomas Mueller added a comment -

          Separation of concern and clearly laid out package structures are both very important of course. But I think that's as easy to achieve when starting with one project as it is when starting with multiple projects. I just think having separate projects too early will only slow us down unnecessarily.

          But if everybody else is feeling we need separate projects right from the start, then that's OK for me.

          Show
          Thomas Mueller added a comment - Separation of concern and clearly laid out package structures are both very important of course. But I think that's as easy to achieve when starting with one project as it is when starting with multiple projects. I just think having separate projects too early will only slow us down unnecessarily. But if everybody else is feeling we need separate projects right from the start, then that's OK for me.
          Hide
          angela added a comment -

          > I just think having separate projects too early will only slow us down unnecessarily.

          how exactly will it slow down someone? i can't follow you here.

          Show
          angela added a comment - > I just think having separate projects too early will only slow us down unnecessarily. how exactly will it slow down someone? i can't follow you here.
          Hide
          Thomas Mueller added a comment -

          > will it slow down someone

          For example, refactoring code is easier if the code is in the same project. At least in the IDE I use (Eclipse).

          Show
          Thomas Mueller added a comment - > will it slow down someone For example, refactoring code is easier if the code is in the same project. At least in the IDE I use (Eclipse).
          Hide
          Dominique Pfister added a comment -

          What about this, Tom: I use Eclipse, too, and if I "mvn eclipse:eclipse" the parent project and open it, it will automatically open all submodules (with the correct build inter-dependencies) and allow me to move classes from one module to the other. Would that work for you?

          Show
          Dominique Pfister added a comment - What about this, Tom: I use Eclipse, too, and if I "mvn eclipse:eclipse" the parent project and open it, it will automatically open all submodules (with the correct build inter-dependencies) and allow me to move classes from one module to the other. Would that work for you?
          Hide
          Thomas Mueller added a comment -

          > if I "mvn eclipse:eclipse" the parent project and open it

          Thanks, I didn't know about this.

          Well, I give up. Create as many components and jar files as you like (oak-jcr, oak-spi, oak-core, oak-commons, and more if you want to). I still don't see what problem we want to solve here, but I will go with whatever you guys decide.

          Show
          Thomas Mueller added a comment - > if I "mvn eclipse:eclipse" the parent project and open it Thanks, I didn't know about this. Well, I give up. Create as many components and jar files as you like (oak-jcr, oak-spi, oak-core, oak-commons, and more if you want to). I still don't see what problem we want to solve here, but I will go with whatever you guys decide.
          Hide
          Jukka Zitting added a comment -

          Looks like we have rough consensus to put this into a separate oak-jcr component, so I created it in revision 1300489. I'll follow up by adding some basic pieces like the above initial test case.

          Michael, would you mind migrating the relevant parts of the existing sandbox code to oak-jcr? I trust your judgement on which codebase is the best basis for future development.

          In oak-core the convention so far was to keep the older prototype code in their original Java packages and to reserve the org.apache.jackrabbit.oak package space for cleaned-up and more future-proof stuff. Ultimately the goal is to be able to drop anything outside o.a.j.oak. In oak-jcr I'd use the o.a.j.oak.jcr package space for a similar purpose.

          Show
          Jukka Zitting added a comment - Looks like we have rough consensus to put this into a separate oak-jcr component, so I created it in revision 1300489. I'll follow up by adding some basic pieces like the above initial test case. Michael, would you mind migrating the relevant parts of the existing sandbox code to oak-jcr? I trust your judgement on which codebase is the best basis for future development. In oak-core the convention so far was to keep the older prototype code in their original Java packages and to reserve the org.apache.jackrabbit.oak package space for cleaned-up and more future-proof stuff. Ultimately the goal is to be able to drop anything outside o.a.j.oak. In oak-jcr I'd use the o.a.j.oak.jcr package space for a similar purpose.
          Hide
          Michael Dürig added a comment -

          I copied the relevant parts from the sandbox [1] into oak-jcr at revision r1301003. The proposed test case passes.

          We should still clean this up and move things into the correct modules. Let's create separate issues for that as we go.

          [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/

          Show
          Michael Dürig added a comment - I copied the relevant parts from the sandbox [1] into oak-jcr at revision r1301003. The proposed test case passes. We should still clean this up and move things into the correct modules. Let's create separate issues for that as we go. [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/
          Hide
          Michael Dürig added a comment -

          fixed at revision 1301003

          Show
          Michael Dürig added a comment - fixed at revision 1301003

            People

            • Assignee:
              Michael Dürig
              Reporter:
              Jukka Zitting
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development