1) Yes, in general. For example imagine a pathological case of loading a class name that is input by the user at runtime. Bnd has no way to know in advance what the class name will be, so it cannot generate the import.

Most code that uses reflection is not quite so pathological as that, and it may follow regular patterns that you can exploit with a bnd plugin. For example if you use a framework that embeds class names in an XML file (e.g. JPA, Blueprint, Spring etc) then it is possible for a plugin to analyse those files and append the imports.

2) This sounds like a mistake. Bnd looks at .class files and doesn't care whether they were compiled from manually written Java sources or from generated sources. You may have an ordering problem in the build, or perhaps the .class files are being generated to the wrong location.

Questions: Did you look inside the bundle to check that the .class files were actually included? Did you include them with <Include-Resource> (which would be bad) or Private-Package/Export-Package (which would be good).

Regards
Neil

11 May 2012 16:05
The documentation says that the plugin will automatically generate Import-Package metadata for you and that you rarely need to state the packages explicitly. I believe I have two cases where it "seems" that I need to be explicit.


1) If my code has a reflection based loading of a particular class, it seems that the plugin doesn't catch it.

2) If I have some generated source code in my maven project, it also seems that the plugin doesn't catch those dependencies.

Are these two cases valid "you have to declare the imports yourself" cases, or am I doing something wrong?

Thanks,
Chad

Reply via email to