ServiceMix 4
  1. ServiceMix 4
  2. SMX4-877

create wrap bundle for axiom API and Impl 1.2.12

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.4.0
    • Component/s: Bundles
    • Labels:
      None

      Description

      Axiom provides OSGi bundle, but there are some issues of these bundles

      • axiom-api exports the package without version
      • axiom-impl never exports the packages in its bundle

      If you are using the axiom-api and axiom-impl bundles with Abdera core in the ServiceMix, you will hit the issue of class not found.

        Issue Links

          Activity

          Hide
          Hudson added a comment -

          Integrated in ws-axiom-trunk #623 (See https://builds.apache.org/job/ws-axiom-trunk/623/)
          Updated the OSGi design with some more information about SMX4-877.

          veithen :
          Files :

          • /webservices/commons/trunk/modules/axiom/src/docbkx/devguide.xml
          Show
          Hudson added a comment - Integrated in ws-axiom-trunk #623 (See https://builds.apache.org/job/ws-axiom-trunk/623/ ) Updated the OSGi design with some more information about SMX4-877 . veithen : Files : /webservices/commons/trunk/modules/axiom/src/docbkx/devguide.xml
          Hide
          Andreas Veithen added a comment -

          Actually the POM for abdera-parser is configured to embed axiom-api as well, but it appears that for some reason that didn't happen in 1.1.2. That problem was reported and fixed by ABDERA-281. Is this issue the reason why the ServiceMix project has chosen to repackage Abdera?

          Show
          Andreas Veithen added a comment - Actually the POM for abdera-parser is configured to embed axiom-api as well, but it appears that for some reason that didn't happen in 1.1.2. That problem was reported and fixed by ABDERA-281 . Is this issue the reason why the ServiceMix project has chosen to repackage Abdera?
          Hide
          Willem Jiang added a comment -

          Hi Andreas,

          Thanks for sharing this impl design principle. It's a good practice not to embed the jars unless you want to hide the implementation bundle.
          I just the checked the abdera-parser bundle of 1.1.2, it has the already embeds the axiom-impl, we don't need to wrap the bundle for axiom Impl in servicemix. But for the axiom-api, it is not a part of abdera-parser, we still need add it as a feature dependency.
          BTW, I also updated the karaf feature of camel and cxf, now they just have the bundle dependency of axiom-api.

          Show
          Willem Jiang added a comment - Hi Andreas, Thanks for sharing this impl design principle. It's a good practice not to embed the jars unless you want to hide the implementation bundle. I just the checked the abdera-parser bundle of 1.1.2, it has the already embeds the axiom-impl, we don't need to wrap the bundle for axiom Impl in servicemix. But for the axiom-api, it is not a part of abdera-parser, we still need add it as a feature dependency. BTW, I also updated the karaf feature of camel and cxf, now they just have the bundle dependency of axiom-api.
          Hide
          Andreas Veithen added a comment -

          This issue is basically invalid. The real problem is that the ServiceMix project has created Abdera bundles that are incorrectly packaged. If you look at the original bundles produced by the Abdera project, you can see that abdera-parser embeds axiom-api and axiom-impl (at least in the trunk, I didn't check the released versions). This means that abdera-parser doesn't import any Axiom packages. That is the correct way of doing things. On the other hand, the Abdera bundles from ServiceMix import packages from axiom-api (which would be OK) and axiom-impl (which is totally wrong, as explained in AXIOM-370).

          I think that by repackaging the whole world and by creating custom bundles that violate the design principles of upstream projects, ServiceMix is not only not helping these communities to produce good bundles (as Dan said above), but actually acting against the interests of these communities. In the case of Axiom, I'm trying to promote a strict separation between the public API and implementation specific classes, and hiding these classes in the OSGi bundles is part of that strategy (although that was originally implemented by somebody else). If the ServiceMix project now publishes repackaged Axiom bundles that export these classes again and people start to use them outside of ServiceMix (which is the case for other repackaged bundles), then this is a bad thing for the progress of the Axiom project.

          Show
          Andreas Veithen added a comment - This issue is basically invalid. The real problem is that the ServiceMix project has created Abdera bundles that are incorrectly packaged. If you look at the original bundles produced by the Abdera project, you can see that abdera-parser embeds axiom-api and axiom-impl (at least in the trunk, I didn't check the released versions). This means that abdera-parser doesn't import any Axiom packages. That is the correct way of doing things. On the other hand, the Abdera bundles from ServiceMix import packages from axiom-api (which would be OK) and axiom-impl (which is totally wrong, as explained in AXIOM-370 ). I think that by repackaging the whole world and by creating custom bundles that violate the design principles of upstream projects, ServiceMix is not only not helping these communities to produce good bundles (as Dan said above), but actually acting against the interests of these communities. In the case of Axiom, I'm trying to promote a strict separation between the public API and implementation specific classes, and hiding these classes in the OSGi bundles is part of that strategy (although that was originally implemented by somebody else). If the ServiceMix project now publishes repackaged Axiom bundles that export these classes again and people start to use them outside of ServiceMix (which is the case for other repackaged bundles), then this is a bad thing for the progress of the Axiom project.
          Hide
          Willem Jiang added a comment -

          Created AXIOM-370, AXIOM-371 with patches for the AXIOM.

          Show
          Willem Jiang added a comment - Created AXIOM-370 , AXIOM-371 with patches for the AXIOM.
          Hide
          Willem Jiang added a comment -

          Changed the axiom version to 1.2.12.

          Show
          Willem Jiang added a comment - Changed the axiom version to 1.2.12.
          Hide
          Daniel Kulp added a comment -

          Can you check 1.2.12 that was just released yesterday?

          Also, make sure you submit a patch back to them. We need to make sure we help the communities produce good bundles, not keep wrapping them.

          Show
          Daniel Kulp added a comment - Can you check 1.2.12 that was just released yesterday? Also, make sure you submit a patch back to them. We need to make sure we help the communities produce good bundles, not keep wrapping them.

            People

            • Assignee:
              Willem Jiang
              Reporter:
              Willem Jiang
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development