You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Guillaume Sauthier (JIRA)" <ji...@apache.org> on 2008/07/22 13:56:31 UTC
[jira] Created: (CXF-1714) ASM package are not stated as optional
imports in the bundle's MANIFEST
ASM package are not stated as optional imports in the bundle's MANIFEST
-----------------------------------------------------------------------
Key: CXF-1714
URL: https://issues.apache.org/jira/browse/CXF-1714
Project: CXF
Issue Type: Wish
Affects Versions: 2.0.7, 2.1.1
Environment: OW2 JOnAS , using CXF in an OSGi gateway (Felix)
Reporter: Guillaume Sauthier
I've found that the package 'org.objectweb.asm' was in the list of Import-Package of the bundle.
It's not described as optional, even if in the code (I looked at the WrapperHelper class) it seems to handle the case where ASM is not present, so I cannot deploy the CXF bundle if the gateway do not have the 'org.objectweb.asm' package available.
So it seems logical to add a resolution:=optional statement in the bnd file.
I have described that issue as a wish because there is a simple workaround: simply provide a bundle exporting the right package; but I don't really like this solution because, I know, from experience, that ASM is not a easily shareable library, because of API incompatibilities, it far more easier to embed its privatized version of ASM (using jarjar or the "new" maven-shadow-plugin its easy) in a private package: org.apache.cxf.asm. So that you don't have to describe the imports because ASM is now part of the distribution + you are sure to never have ASM version incompatibilities issue. Moreover, the ASM core is really lightweight...
So to sum up, I have 2 solutions:
1. add resolution:=optional to the import statement
2. or privatize ASM automatically
My preference goes to #2 :)
BTW, does that make sens to have a "Bundle" component in JIRA, or the OSGi issues will go to the "Build system" component ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1714) ASM package are not stated as optional
imports in the bundle's MANIFEST
Posted by "Guillaume Sauthier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620232#action_12620232 ]
Guillaume Sauthier commented on CXF-1714:
-----------------------------------------
Any news on this topic ?
Do you want a patch ?
> ASM package are not stated as optional imports in the bundle's MANIFEST
> -----------------------------------------------------------------------
>
> Key: CXF-1714
> URL: https://issues.apache.org/jira/browse/CXF-1714
> Project: CXF
> Issue Type: Wish
> Affects Versions: 2.1.1, 2.0.7
> Environment: OW2 JOnAS , using CXF in an OSGi gateway (Felix)
> Reporter: Guillaume Sauthier
>
> I've found that the package 'org.objectweb.asm' was in the list of Import-Package of the bundle.
> It's not described as optional, even if in the code (I looked at the WrapperHelper class) it seems to handle the case where ASM is not present, so I cannot deploy the CXF bundle if the gateway do not have the 'org.objectweb.asm' package available.
> So it seems logical to add a resolution:=optional statement in the bnd file.
> I have described that issue as a wish because there is a simple workaround: simply provide a bundle exporting the right package; but I don't really like this solution because, I know, from experience, that ASM is not a easily shareable library, because of API incompatibilities, it far more easier to embed its privatized version of ASM (using jarjar or the "new" maven-shadow-plugin its easy) in a private package: org.apache.cxf.asm. So that you don't have to describe the imports because ASM is now part of the distribution + you are sure to never have ASM version incompatibilities issue. Moreover, the ASM core is really lightweight...
> So to sum up, I have 2 solutions:
> 1. add resolution:=optional to the import statement
> 2. or privatize ASM automatically
> My preference goes to #2 :)
> BTW, does that make sens to have a "Bundle" component in JIRA, or the OSGi issues will go to the "Build system" component ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1714) ASM package are not stated as optional
imports in the bundle's MANIFEST
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621054#action_12621054 ]
Daniel Kulp commented on CXF-1714:
----------------------------------
We'd love a patch. :-)
> ASM package are not stated as optional imports in the bundle's MANIFEST
> -----------------------------------------------------------------------
>
> Key: CXF-1714
> URL: https://issues.apache.org/jira/browse/CXF-1714
> Project: CXF
> Issue Type: Wish
> Affects Versions: 2.1.1, 2.0.7
> Environment: OW2 JOnAS , using CXF in an OSGi gateway (Felix)
> Reporter: Guillaume Sauthier
>
> I've found that the package 'org.objectweb.asm' was in the list of Import-Package of the bundle.
> It's not described as optional, even if in the code (I looked at the WrapperHelper class) it seems to handle the case where ASM is not present, so I cannot deploy the CXF bundle if the gateway do not have the 'org.objectweb.asm' package available.
> So it seems logical to add a resolution:=optional statement in the bnd file.
> I have described that issue as a wish because there is a simple workaround: simply provide a bundle exporting the right package; but I don't really like this solution because, I know, from experience, that ASM is not a easily shareable library, because of API incompatibilities, it far more easier to embed its privatized version of ASM (using jarjar or the "new" maven-shadow-plugin its easy) in a private package: org.apache.cxf.asm. So that you don't have to describe the imports because ASM is now part of the distribution + you are sure to never have ASM version incompatibilities issue. Moreover, the ASM core is really lightweight...
> So to sum up, I have 2 solutions:
> 1. add resolution:=optional to the import statement
> 2. or privatize ASM automatically
> My preference goes to #2 :)
> BTW, does that make sens to have a "Bundle" component in JIRA, or the OSGi issues will go to the "Build system" component ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.