Paul Sandoz wrote:
>
> On Oct 8, 2008, at 11:22 AM, Sahoo wrote:
>
>> Jakub Podlesak wrote:
>>> On Wed, Oct 08, 2008 at 08:08:38AM +0530, Sahoo wrote:
>>>
>>>> That bundle is an implementation artifact and is not to be used by
>>>> applications. Since applications can't always use the version of
>>>> ASM that server requires, we have to hide the version that server
>>>> requires. We do so by using those extra attributes. Only people who
>>>> deploy OSGi bundles can use that bundle if they suitably specify
>>>> the import headers in their bundles, but that does not apply to
>>>> normal web app deployment.
>>>
>>> I am in fact adding a Jersey based module
>>> to GlassFish, so that users could deploy Jersey based apps without a
>>> need
>>> to bundle additional jars into their wars.
>>>
>>> So i believe there are two possible ways how to resolve the asm-3.1
>>> dependency
>>> for Jersey module here:
>>>
>>> 1. Jersey module would use the required GlassFish specific attributes
>>> in the ImportPackages header for the asm related packages
>>>
>>> 2. I would provide an OSGified asm 3.1 module and put it into
>>> GlassFish modules.
>>> It shouldn't create any conflict with your privately updated
>>> [asm-all-repackaged.jar]
>>> module, as you use a GlassFish specific attributes in it's OSGi headers
>>> Is my assumptions correct?
>>>
>>>
>> Yes, they are correct. If you can use #1, then better as it increases
>> sharing of classes.
>>
>
> #1 would make the Jersey module GF specific,
Not really. Specifying that extra attribute in Import-Package does not
make it GF specific.
Thanks,
Sahoo