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.
>
You are right. If there are such packages, then the tool has to be told
about them. BTW, is glassfish-api not the right bundle to export such
packages?
>
> 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.
No, this is not true. Packages of the services don't have to be
exported. Only the service interface package has to be exported.
>
>> 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?
The tool does not look at osgi.bundle file. Let's first build a list of
such packages and add it to the Wiki. Then we will see how to feed it to
the tool.
Thanks,
Sahoo