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.
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
>