Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: core
    • Labels:
      None

      Description

      imo we should clean up the org.apache.jackrabbit.mk.* packages that are currently
      located in the oak-core module.

      for me it is really hard to destinguish between code that is really part of the
      productive code base for the oak project and code that is purely experimental
      chunk and leftover.

      in order to become familiar with the code that would be helpful for me and
      anybody else that will contribute to the project.

        Issue Links

          Activity

          angela created issue -
          Hide
          Dominique Pfister added a comment -

          I can comment on the packages/classes I created:

          o.a.j.mk.cluster: there's not much going on here and I can delete that

          o.a.j.mk.client/server: these contain code for exposing/accessing an MK implementation over HTTP, along with some static resources that provide a very simple browser interface, where every method of the MicroKernel interface is mapped to some HTML page with a form that can be submitted to actually invoke the method on the running MK, which I originally created to get acquainted with the MK API. Not sure whether we want to keep this.

          Show
          Dominique Pfister added a comment - I can comment on the packages/classes I created: o.a.j.mk.cluster: there's not much going on here and I can delete that o.a.j.mk.client/server: these contain code for exposing/accessing an MK implementation over HTTP, along with some static resources that provide a very simple browser interface, where every method of the MicroKernel interface is mapped to some HTML page with a form that can be submitted to actually invoke the method on the running MK, which I originally created to get acquainted with the MK API. Not sure whether we want to keep this.
          Hide
          Thomas Mueller added a comment -

          The packages I created:

          org.apache.jackrabbit.mk.blobs:
          data store,
          used in MicroKernel implementations,
          should be kept

          org.apache.jackrabbit.mk.fs:
          file system abstraction,
          used by the data store, temp files,
          should be kept

          org.apache.jackrabbit.mk.index:
          property index implementation,
          should be kept

          org.apache.jackrabbit.mk.json.Jsop*:
          json diff builders and tokenizers (stax-style parsers),
          used in MicroKernel implementations,
          should be kept

          (org.apache.jackrabbit.mk.json.JsonBuilder is not from me so I can't comment here)

          org.apache.jackrabbit.mk.json.fast:
          json diff dom-style builder and parser,
          used in some tests and Dominiques HotBackup,
          not sure if really required - I guess it would make
          sense to keep it for the test cases, possibly could be moved
          back to the src/test tree

          org.apache.jackrabbit.mk.simple:
          an alternative MicroKernel implementation (database, in-memory, mongodb),
          should be kept

          org.apache.jackrabbit.mk.util:
          not everything is from me,
          most classes should be kept (we can discuss the details)

          org.apache.jackrabbit.mk.wrapper:
          MicroKernel wrapper implementations,
          should be kept I think (we can discuss),

          Show
          Thomas Mueller added a comment - The packages I created: org.apache.jackrabbit.mk.blobs: data store, used in MicroKernel implementations, should be kept org.apache.jackrabbit.mk.fs: file system abstraction, used by the data store, temp files, should be kept org.apache.jackrabbit.mk.index: property index implementation, should be kept org.apache.jackrabbit.mk.json.Jsop*: json diff builders and tokenizers (stax-style parsers), used in MicroKernel implementations, should be kept (org.apache.jackrabbit.mk.json.JsonBuilder is not from me so I can't comment here) org.apache.jackrabbit.mk.json.fast: json diff dom-style builder and parser, used in some tests and Dominiques HotBackup, not sure if really required - I guess it would make sense to keep it for the test cases, possibly could be moved back to the src/test tree org.apache.jackrabbit.mk.simple: an alternative MicroKernel implementation (database, in-memory, mongodb), should be kept org.apache.jackrabbit.mk.util: not everything is from me, most classes should be kept (we can discuss the details) org.apache.jackrabbit.mk.wrapper: MicroKernel wrapper implementations, should be kept I think (we can discuss),
          angela made changes -
          Field Original Value New Value
          Component/s core [ 12317803 ]
          Hide
          Stefan Guggisberg added a comment -

          thanks for bringing this up.

          i completely agree with angela (once again .

          org.apache.jackrabbit.mk.* is a real mess.
          there are 2 largely independent mk implementations
          which IMO is totally confusing.

          while i am convinced that we should allow for
          alternative mk implementations we should
          separate them with independent source trees/poms.

          everything else doesn't make sense IMO.

          i would also suggest to designate a 'default'
          implementation for the oak project. that 'default'
          could serve as a reference implementation of
          the MicroKernel API.

          Show
          Stefan Guggisberg added a comment - thanks for bringing this up. i completely agree with angela (once again . org.apache.jackrabbit.mk.* is a real mess. there are 2 largely independent mk implementations which IMO is totally confusing. while i am convinced that we should allow for alternative mk implementations we should separate them with independent source trees/poms. everything else doesn't make sense IMO. i would also suggest to designate a 'default' implementation for the oak project. that 'default' could serve as a reference implementation of the MicroKernel API.
          angela made changes -
          Component/s mk [ 12317814 ]
          Component/s core [ 12317803 ]
          Michael Dürig made changes -
          Link This issue incorporates OAK-92 [ OAK-92 ]
          Stefan Guggisberg made changes -
          Component/s core [ 12317803 ]
          Component/s mk [ 12317814 ]
          Hide
          Michael Dürig added a comment -

          To finalise this I propose to:

          • move o.a.j.mk.index to o.a.j.oak.query.index
          • move everything which is required for the query implementation in oak core from o.a.j.mk.simpl to o.a.j.oak.query or an adequate sub-package thereof.
          • move o.a.j.mk.wrapper to a utility package in oak-mk since this package essentially contains Microkernel implementations.
          • move the classes in o.a.j.mk.util to util packages in oak-mk, oak-core or oak-commons as required.
          • move o.a.j.mk.MicroKernelFactory to oak-mk since this class is concernd with Microkernel implementations only.
          • move the Simple implementation in o.a.j.mk.simple either to an package experimental in oak-mk, to an own sub-module oak-experimental or to the sandbox.
          Show
          Michael Dürig added a comment - To finalise this I propose to: move o.a.j.mk.index to o.a.j.oak.query.index move everything which is required for the query implementation in oak core from o.a.j.mk.simpl to o.a.j.oak.query or an adequate sub-package thereof. move o.a.j.mk.wrapper to a utility package in oak-mk since this package essentially contains Microkernel implementations. move the classes in o.a.j.mk.util to util packages in oak-mk, oak-core or oak-commons as required. move o.a.j.mk.MicroKernelFactory to oak-mk since this class is concernd with Microkernel implementations only. move the Simple implementation in o.a.j.mk.simple either to an package experimental in oak-mk, to an own sub-module oak-experimental or to the sandbox.
          Hide
          Thomas Mueller added a comment -

          The index component is still under heavy development. I will rename the packages once I figure out how to best do that.

          Show
          Thomas Mueller added a comment - The index component is still under heavy development. I will rename the packages once I figure out how to best do that.
          Hide
          Stefan Guggisberg added a comment - - edited

          > To finalise this I propose to:
          >
          > * move o.a.j.mk.index to o.a.j.oak.query.index
          > * move everything which is required for the query implementation in oak core from o.a.j.mk.simpl to o.a.j.oak.query or an adequate sub-package thereof.
          > * move o.a.j.mk.wrapper to a utility package in oak-mk since this package essentially contains Microkernel implementations.

          the problem is that some classes in the o.a.j.mk.wrapper package have dependencies on o.a.j.mk.simple code.
          if they would only depend on the MicroKernel api i'd suggest to move them to new module (e.g. oak-mk-commons).

          > * move the classes in o.a.j.mk.util to util packages in oak-mk, oak-core or oak-commons as required.
          > * move o.a.j.mk.MicroKernelFactory to oak-mk since this class is concernd with Microkernel implementations only.

          -1, we should try to resolve the MicroKernelFactory issue instead of moving it around. see [1] for a related discussion.

          > * move the Simple implementation in o.a.j.mk.simple either to an package experimental in oak-mk, to an own sub-module oak-experimental or to the sandbox.

          -1 for moving it to oak-mk. we had that situation (different implementations in the same module) before. i'd like to avoid that because it's IMO confusing.

          [1] http://oak.markmail.org/thread/j34cd5m6ti5nwuit

          Show
          Stefan Guggisberg added a comment - - edited > To finalise this I propose to: > > * move o.a.j.mk.index to o.a.j.oak.query.index > * move everything which is required for the query implementation in oak core from o.a.j.mk.simpl to o.a.j.oak.query or an adequate sub-package thereof. > * move o.a.j.mk.wrapper to a utility package in oak-mk since this package essentially contains Microkernel implementations. the problem is that some classes in the o.a.j.mk.wrapper package have dependencies on o.a.j.mk.simple code. if they would only depend on the MicroKernel api i'd suggest to move them to new module (e.g. oak-mk-commons). > * move the classes in o.a.j.mk.util to util packages in oak-mk, oak-core or oak-commons as required. > * move o.a.j.mk.MicroKernelFactory to oak-mk since this class is concernd with Microkernel implementations only. -1, we should try to resolve the MicroKernelFactory issue instead of moving it around. see [1] for a related discussion. > * move the Simple implementation in o.a.j.mk.simple either to an package experimental in oak-mk, to an own sub-module oak-experimental or to the sandbox. -1 for moving it to oak-mk. we had that situation (different implementations in the same module) before. i'd like to avoid that because it's IMO confusing. [1] http://oak.markmail.org/thread/j34cd5m6ti5nwuit
          Hide
          Thomas Mueller added a comment -

          I will take some more time until the index implementation and API is ready for larger refactorings. And larger refactorings will be needed, we might even decide that the whole 'content index' mechanism (IndexWrapper, Indexer) is not needed once we have a Lucene implementation (if it turns out this implementation is much faster than the content index). I suggest we wait with refactoring this area until we have performance data from a Lucene index implementation.

          A bit simpler might be the MicroKernelFactory (I wanted to replace it with an interface). Such an interface could also be moved to oak-mk or oak-commons I guess.

          Show
          Thomas Mueller added a comment - I will take some more time until the index implementation and API is ready for larger refactorings. And larger refactorings will be needed, we might even decide that the whole 'content index' mechanism (IndexWrapper, Indexer) is not needed once we have a Lucene implementation (if it turns out this implementation is much faster than the content index). I suggest we wait with refactoring this area until we have performance data from a Lucene index implementation. A bit simpler might be the MicroKernelFactory (I wanted to replace it with an interface). Such an interface could also be moved to oak-mk or oak-commons I guess.
          Hide
          Thomas Mueller added a comment -

          > (different implementations in the same module)

          Hm, there are already 2 MicroKernel implementations in oak-mk: MicroKernelImpl and Client...

          Show
          Thomas Mueller added a comment - > (different implementations in the same module) Hm, there are already 2 MicroKernel implementations in oak-mk: MicroKernelImpl and Client...
          Hide
          Thomas Mueller added a comment -

          Something (hopefully) less controversial:

          What about moving the Jsop classes from oak-mk to oak-commons?
          And moving org.apache.jackrabbit.mk.json.fast from oak-core (test) to the same module (also test at this time)?

          Show
          Thomas Mueller added a comment - Something (hopefully) less controversial: What about moving the Jsop classes from oak-mk to oak-commons? And moving org.apache.jackrabbit.mk.json.fast from oak-core (test) to the same module (also test at this time)?
          Hide
          Michael Dürig added a comment -

          Cleaning up old issues. Please reopen if necessary. Consider opening a new issue for follow up work.

          Show
          Michael Dürig added a comment - Cleaning up old issues. Please reopen if necessary. Consider opening a new issue for follow up work.
          Michael Dürig made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 0.7 [ 12323981 ]
          Resolution Fixed [ 1 ]
          Jukka Zitting made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              angela
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development