[
https://issues.apache.org/jira/browse/FELIX-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch closed FELIX-945.
----------------------------------
Resolution: Won't Fix
In my opinion this is working as designed.
The Bnd Tool works from the class bytecode, not the source, and the bytecode
clearly has a reference to a class from "javax.print.attribute". Now it may be
that this is not actually used at runtime, but I think it would be too
dangerous to discard references on the off-chance they might not be needed. I
mean, the compiler left the reference in there so it's possible that some tool
could try to access it via reflection - and then you would need the import.
To sum up, the Bnd Tool uses a simple form of bytecode scanning to calculate
imports - there are corner cases where it might miss imports (such as dynamic
lookup based on a calculated string) or include unnecessary imports (such as
here, or references to code only used in certain scenarios, such as when
third-party libraries include Ant tasks). Either way, it is the responsibility
of the bundle developer to review the automatically generated imports and add
the necessary inclusions, exclusions, and version ranges.
For example, here you could easily add:
<Import-Package>!javax.print.attribute,*</Import-Package>
if you are certain this package is not required.
> bundle-plugin generates Import-Package for method return types even when
> returned object is not used
> ----------------------------------------------------------------------------------------------------
>
> Key: FELIX-945
> URL: https://issues.apache.org/jira/browse/FELIX-945
> Project: Felix
> Issue Type: Bug
> Affects Versions: maven-bundle-plugin-1.4.3
> Environment: generic
> Reporter: Sahoo
> Attachments: Felix-945.zip
>
>
> It is probably a bug in bnd, but it probably also needs a fix in bundle
> plugin in a sense that a new version of bnd needs to be integrated to fix the
> issue. My class does this:
> void foo(javax.print.Doc foo) throws Exception {
> foo.getAttributes();
> }
> As you can see, it just calls javax.print.Doc.getAttributes(), but ignores
> the returned object, which in this case is of type javax.print.attribute.
> Yet, the generated Import-Package contained javax.print.attribute package. A
> complete test case is attached here with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
