Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.1
    • Fix Version/s: 0.2.1
    • Component/s: core
    • Labels:
      None

      Description

      Since the plan for the 0.2 release intents to add initial OSGi budling functionality, we need to track this addition.

      Will come up with a patch and change proposal for such bundling.

      1. OAK-67.patch
        8 kB
        Felix Meschberger

        Issue Links

          Activity

          Hide
          Felix Meschberger added a comment -

          This is part of making Oak OSGi-friendly

          Show
          Felix Meschberger added a comment - This is part of making Oak OSGi-friendly
          Hide
          Felix Meschberger added a comment -

          Creating proper OSGi bundles also requires removing all MK stuff from the oak-core module.

          Show
          Felix Meschberger added a comment - Creating proper OSGi bundles also requires removing all MK stuff from the oak-core module.
          Hide
          Felix Meschberger added a comment -

          Here is a first shot at a patch.

          Assumptions (which may be slightly wrong):

          • mk exports .api, .json, and .util
          • core exports .api
          • jcr does not export anything

          All packages are currently exported at version 0.1. These versions should evolve over time, yet I would assume that version 1.0 of the exports will only be used once we do the 1.0 release of Oak.

          There are a number of problems with the current code structure:

          • An explicit Export-Package statement is needed in each module because by default the bundle plugin exports anything not inside (below) an impl or internal package.
          • Core still contains MK stuff referring to packages presumably private to the MK module (see also OAK-57)
          • QueryEngine and ResultRow in core .api refer to CoreValue residing in a non-exported package. This should be fixed (move CoreValue or don't refer to CoreValue)
          • To make it easier to decide between public (externally usable) and internal packages, I suggest to move internal packages below a common packages, e.g. o.a.j.mk.internal.* for the MK module. This assists users to identify presumably internal code and helps the bundle plugin in deciding what to export and what not.
          Show
          Felix Meschberger added a comment - Here is a first shot at a patch. Assumptions (which may be slightly wrong): mk exports .api, .json, and .util core exports .api jcr does not export anything All packages are currently exported at version 0.1. These versions should evolve over time, yet I would assume that version 1.0 of the exports will only be used once we do the 1.0 release of Oak. There are a number of problems with the current code structure: An explicit Export-Package statement is needed in each module because by default the bundle plugin exports anything not inside (below) an impl or internal package. Core still contains MK stuff referring to packages presumably private to the MK module (see also OAK-57 ) QueryEngine and ResultRow in core .api refer to CoreValue residing in a non-exported package. This should be fixed (move CoreValue or don't refer to CoreValue) To make it easier to decide between public (externally usable) and internal packages, I suggest to move internal packages below a common packages, e.g. o.a.j.mk.internal.* for the MK module. This assists users to identify presumably internal code and helps the bundle plugin in deciding what to export and what not.
          Hide
          Jukka Zitting added a comment -

          +1 looks good

          On the last point, instead of using .internal.* packages, I'd rather have everything private by default and only stuff in .api exported by default.

          Show
          Jukka Zitting added a comment - +1 looks good On the last point, instead of using .internal.* packages, I'd rather have everything private by default and only stuff in .api exported by default.
          Hide
          Felix Meschberger added a comment -

          I am ok with just exportin .api. But what about .util ?

          I would really find it easily informative to have packages intended for internal use only clearly
          marked with a kind-of-tag in the package.

          For example o.a.j.mk.util may be seen as internal or external ... but o.a.j.mk.internal.util will
          never be mistaken to be external.

          Show
          Felix Meschberger added a comment - I am ok with just exportin .api. But what about .util ? I would really find it easily informative to have packages intended for internal use only clearly marked with a kind-of-tag in the package. For example o.a.j.mk.util may be seen as internal or external ... but o.a.j.mk.internal.util will never be mistaken to be external.
          Hide
          Jukka Zitting added a comment -

          I committed the patch and some followup changes, including an initial test case, OSGi services for key components, and a separate oak-sling bundle that implements (badly) the SlingRepository extension interface in addition to standard JCR Repository.

          There's a lot of things to clean up, not least the various package export settings, but let's handle those as separate followup issues, as the basic setup is now already in place.

          Show
          Jukka Zitting added a comment - I committed the patch and some followup changes, including an initial test case, OSGi services for key components, and a separate oak-sling bundle that implements (badly) the SlingRepository extension interface in addition to standard JCR Repository. There's a lot of things to clean up, not least the various package export settings, but let's handle those as separate followup issues, as the basic setup is now already in place.

            People

            • Assignee:
              Jukka Zitting
              Reporter:
              Felix Meschberger
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development