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

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          2d 7h 19m 1 Jukka Zitting 25/Apr/12 17:02
          Resolved Resolved Closed Closed
          8d 17h 30m 1 Alex Parvulescu 04/May/12 10:33
          Gavin made changes -
          Link This issue depends upon OAK-57 [ OAK-57 ]
          Gavin made changes -
          Link This issue depends on OAK-57 [ OAK-57 ]
          Alex Parvulescu made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Alex Parvulescu made changes -
          Fix Version/s 0.2.1 [ 12321252 ]
          Fix Version/s 0.2 [ 12320344 ]
          Jukka Zitting made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Jukka Zitting [ jukkaz ]
          Resolution Fixed [ 1 ]
          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.
          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 -

          +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.
          Felix Meschberger made changes -
          Attachment OAK-67.patch [ 12523772 ]
          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
          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.
          Felix Meschberger made changes -
          Link This issue depends on OAK-57 [ OAK-57 ]
          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
          Felix Meschberger made changes -
          Field Original Value New Value
          Link This issue is part of OAK-17 [ OAK-17 ]
          Felix Meschberger created issue -

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development