In a refactoring today I was moving some classes to another bundle.
I forgot some Util class which was in an internal (not exported) package of the old bundle.
Since I added the old bundle to the buildpath of the new bundle it compiled fine in Eclipse - at first glance. But the app did not start, because of the usual “Unresolved requirement” errors.
What I didn’t notice: the import statement in the moved classes for the Util-class in the old bundle had this yellow warning icon and underline from Eclipse saying “Discouraged access: the method .... is not API”
Then I noticed that this is also shown in the Problems view, but in the Java-Section… A bit further down, so I didn’t notice it immediately.
Once I exported the package of the Util-class in the old bundle everything was fine.
Question:
It was clearly my mistake but:
Eclipse did in fact tell me what was wrong (but a bit not obvious enough). Bndtools did not, only when I started the app in the console.
I would have expected bndtools yelling at me somehow.
What do you think? Should this be bnd to recognize this too somehow? And where?
Resolution view? bnd.bnd file?
Since I recently did some work on the Resolution view, I tried making it visible there somehow… but failed (maybe due to the late hour). e.g. I marked both bundles (which I know where involved) in the Repo-Browser to see the aggregated resolution view, to see if the culprit package was highlighted somehow. But it wasn’t. In only could see it indirectly… e.g. I saw that
new Bundle B had an entry in the Requirements panel of the internal package
and I saw that the internal package, did not show up in the Capabilities panel
But I would have liked it to me more in my face. Because both facts I could only infer, because I knew the solution. If I didn’t know it, it would be more needle haystack searching.
Thoughts?
I can invest some time into a PR, but first I’d like to find out if my expectation is correct, and what solution would be useful.
This is why you need a workspace that has no warnings … Then these details show.
If you want to make it an error, use -fixupmessage. I think it should be a warning because it could be useful in combination with the -conditionalpackage. i.e. that will just copy those classes.
What do you think? Should this be bnd to recognize this too somehow? And where?
Resolution view? bnd.bnd file?
I’ve had my head deep in this code - this warning is generated by the Eclipse JavaBuilder, not by Bnd/tools. Here’s how it works:
Bndtools configures the Bnd Bundle Path container in your Eclipse project. It is based on the settings in your .bnd file (in particular, -buildpath and -testpath (BndContainerInitializer).
The Bnd Bundle Path container (as with all containers) contains a list of jars or other Eclipse workspace projects.
When an creates library entries on the classpath, it can specify access rules. This was obviously first created to support PDE but has been used by Bndtools for the same purpose. So when BndClasspathInitializer tools creates the library classpath entries, it looks for private packages in the jar and flags them as having restricted access.
The Eclipse compiler will then report the “Discouraged Access” warning if it notices during compilation that the dependency is sourced from a class with restricted access.
I give you this detail in case you feel like getting your hands dirty…
I am not sure if @pkriens’ suggestion to use -fixupmessage will work, because this error message is not generated by Bnd/tools - it’s generated by Eclipse JavaBuilder. But you can configure Eclipse to report “Discouraged Access” as warnings as errors, I believe.
I’m not sure if this error would happen if building/compiling on the command line using Gradle or Maven - I expect not, because they use javac which doesn’t have the concept of packages in a jar that aren’t supposed to be accessible (except maybe using modules, somehow?). It would be possible for the Maven/Gradle plugins to emulate this behaviour by repackaging the jar to include only exported packages, and then compile against those.
As for whether Bnd should also report the same error: I’m open to suggestions, but I think that really this is as it should be. In Bnd/tools there is a sharp distinction between build-time dependencies and runtime dependencies. At runtime, your bundle might import the package from another bundle that exports it, or else you might include the package in your own bundle (@pkriens also mentioned -conditionalpackage that can be used to do this).
I like this explanation. The current Eclipse Warning should be this It would tell the developer at build-time that something “might” be incorrect.
I think we can leave it as is. I am leaning towards Peters suggestion - the sisyphus work of clearning up our historical baggage, to achieve a workspace with no warnings
