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: *." 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.
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
>