On 05/06/2010 08:37 AM, Tim Quinn wrote:
>
> On May 6, 2010, at 10:03 AM, Sahoo wrote:
>
>> I certainly don't expect all unused exports to go away, but majority
>> should. The report is generated from OSGi meta data, so it is not a
>> reflection of build time dependencies. AFAIK, the only reason a
>> package which is actually needed by some other bundle shows up as
>> unused is because the other bundle does not have an Import-Package
>> header for the package, instead it uses a DynamicImport-Package
>> header. Typically this happens in GlassFish via our application class
>> loader which has a "DynamicImport-Package: *."
>
> DynamicImport-Package is the only reason?
>
> In my earlier note I mentioned two other use cases, neither of which
> involve DynamicImport-Package headers in GlassFish modules:
>
> 1. Modules which export packages that are not imported in any way by
> other GlassFish OSGi modules but are intended to be imported by
> user-built modules.
>
> One example is appclient/client (gf-client-module.jar). The
> GlassFish-provided JAR that refers to this JAR is not an OSGi-module,
> so there is no [Dynamic]Import-Package directive in any GlassFish
> module. But we want to allow users to build their own OSGi modules
> that do use OSGi package imports from that module. I don't know if
> there are other modules in GlassFish we envision being used this way,
> but that is at least one.
The Admin console plugin code falls under this use case for a limited
number of our API's.
Ken
> 2. Modules that hk2 scans to discover implementations of interfaces.
> For example, Sniffer implementations.
>
> The hk2 code looks at all the JARs that have been placed in the
> modules directory, searching each for inhabitants. The hk2 module
> does not declare imports of such modules - it cannot know about them
> at the time hk2 is built.
>
> Yet hk2 is using OSGi loading techniques, so the relevant packages
> must be exported from the OSGi modules even thought no other OSGi
> module in the reporting tool's survey imports those packages at all.
>
>> If we identify such packages, then we can feed it into the tool so
>> that the tool won't report them as unused any more. Again, only
>> module owners know what are those packages. Once we have identified
>> the packages, I can change the tool accept it as an input.
>
> Do you want module owners to let you know what these packages are? Or
> is there some way to augment the osgi.bundle content to indicate
> this? Or is there some other place owners should record this
> information so the tool will find it?
>
> Thanks.
>
> - Tim
>
>>
>> Thanks,
>> Sahoo
>>
>> Tim Quinn wrote:
>>> Sahoo,
>>>
>>> I think you need to add something to the reporting so we can exempt
>>> certain cases in which GlassFish itself might not refer to an
>>> exported package - and therefore it shows up as "unused" in the
>>> report - but users writing their own OSGi modules would need to see
>>> the package and therefore it must be exported.
>>>
>>> Also, we will always have this, for example, for our container
>>> modules which are loaded dynamically and therefore must export
>>> packages that will be needed at runtime even though they might not
>>> be referenced at build-time.
>>>
>>> Or have I misunderstood something?
>>>
>>> - Tim
>>>
>>> On May 6, 2010, at 12:03 AM, Sahoo wrote:
>>>
>>>> As discussed in the last engg. meeting, the link to the Wiki page I
>>>> have created for this purpose is:
>>>>
>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=OsgiPkgDepAnalyser
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>