Community
Participate
Working Groups
Almost all of the provisional API in p2 (e.g. o.e.e.i.provisional.p2.metadata) is currently marked as "hidden" packages in the manifest. This causes discouraged access warnings on all downstream bundles that use the provisional API. For example, we have 170 compile warnings in o.e.w.server.discovery in WTP. What's the policy on access restrictions for provisional API? I can see the logic behind making classes hidden until they are full API, but the package names will change anyway, and the drawback is that any real internal usage is lost in the sea of provisional warnings - in fact I have to turn off all discouraged access warnings just to see regular compile warnings. If the policy is to discourage all access until there is real API, then please go ahead and close this bug. Otherwise, please use it to remove the access restrictions on provisional packages so that we can have a clear view of whether we're using the right (provisional) API.
Agreed this is a pain. See http://wiki.eclipse.org/Provisional_API_Guidelines_Update_Proposal and bug 261874 bug 234947 for related discussions.
*** Bug 274959 has been marked as a duplicate of this bug. ***
No plan to change this. We are following the policy outlined here: http://wiki.eclipse.org/Provisional_API_Guidelines_Update_Proposal#Guidelines_for_producers_of_provisional_API As Jeff mentions, improved tooling could help ease the pain here. But, we need to err on the side of making sure consumers are aware they are referencing unsupported code that may have breaking changes in the future.
The problem is less being aware of provisional code and more that this masks any other errors or actual usage of internal code. Consider the case above where I had one error amid 170 discouraged access warnings. If I leave the discouraged access warnings visible I literally can't find other problems without carefully stepping through the list one by one. If I turn discouraged access warnings off, I'll accidentally hide real (non-provisional) internal usage, and also will be unable to report missing API back to p2. It's a no-win situation. Since you're following the guidelines and suggest this could be handled in the tools instead, I'll reopen and transfer to PDE.
Reassigning to PDE UI.
(In reply to comment #4) > Consider the case above where I had one error amid 170 discouraged access > warnings. If I leave the discouraged access warnings visible I literally can't > find other problems without carefully stepping through the list one by one. If > I turn discouraged access warnings off, I'll accidentally hide real > (non-provisional) internal usage, and also will be unable to report missing API > back to p2. It's a no-win situation. Perhaps this should be marked as a duplicate of bug 234947. There are similar complaints in the comments.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
*** This bug has been marked as a duplicate of bug 234947 ***
