Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
WTP: Consumer Control of Access Rules
Introduction
Access rules are an important part of declaring and documenting a component's API. This is typically done by marking packages as x-internal in the manifest.mf file, and in some cases, declaring your known "friends" with the x-friend directive. In WTP things should be "friends" only if they are in the same feature-component, according to our defined "build features", and as documented in Subsystems and Features.
This conservative approach is done to be useful to adopters, making clear what is not API (yet), but is problematic for WTP itself, since we still have not evolved all our intended API, so even our own code "violate" our API. Of course, these are not very bad violations for WTP, since we'll be releasing everything "in sync" for at least another release or two.
In the mean time, this approach causes too many warnings in the development environment, so the discouraged access warnings have to be turned off or filtered out ... which means we miss important warnings, where we violate someone else's internal packages.
The Solution
There is a capability in the Eclipse Development environment that we in WTP should take advantage of. While, normally, access rules are defined "from below" by the supplied plugins, there is a capability in the IDE to tweak the access rules "from above" so that we, as consumers, can accept certain risks, but still be informed of other violations.
One easy example is that everything in JST can, for now, pretty safely use anything in WST, even though we would not want to declare the WST methods as API (at least yet). So, JST classes using WST classes is an acceptable risk for WTP.
The Method
To tweak the access rules "from above" there are two methods, modify the build path properties using the provided UI, or, "manually" edited the .classpath file ... the UI method is usually recommended, and the .classpath is a system file, and normally users should not be hand editing those.
The Edit Access Rule UI
Pretty easy once you see where it is.